* we give editing
From: Julian Jones @ 2018-08-08 11:28 UTC (permalink / raw)
To: netdev
You have needs for image editing for our studio?
Our studio does different image editing for e-commerce photos, jewelry
images, and portrait mages.
It includes cutting out and clipping path and the others, like retouching
etc.
Drop us a photo, testing will be provided.
Thanks,
Julian
^ permalink raw reply
* Re: [PATCH net-next v6 11/11] net: sched: change action API to use array of pointers to actions
From: Cong Wang @ 2018-08-08 18:29 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Jiri Pirko, Alexei Starovoitov, Daniel Borkmann,
Yevgeny Kliteynik
In-Reply-To: <vbfr2j92ii3.fsf@reg-r-vrt-018-180.mtr.labs.mlnx>
On Wed, Aug 8, 2018 at 4:41 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>
>
> On Tue 07 Aug 2018 at 23:26, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > On Thu, Jul 5, 2018 at 7:24 AM Vlad Buslov <vladbu@mellanox.com> wrote:
> >> attr_size = tcf_action_full_attrs_size(attr_size);
> >>
> >> if (event == RTM_GETACTION)
> >> - ret = tcf_get_notify(net, portid, n, &actions, event, extack);
> >> + ret = tcf_get_notify(net, portid, n, actions, event, extack);
> >> else { /* delete */
> >> - ret = tcf_del_notify(net, n, &actions, portid, attr_size, extack);
> >> + ret = tcf_del_notify(net, n, actions, &acts_deleted, portid,
> >> + attr_size, extack);
> >> if (ret)
> >> goto err;
> >> return ret;
> >> }
> >> err:
> >> - tcf_action_put_lst(&actions);
> >> + tcf_action_put_many(&actions[acts_deleted]);
> >> return ret;
> >
> > How does this even work?
> >
> > You save an index in 'acts_deleted', but you pass &actions[acts_deleted]
> > to tcf_action_put_many(), which seems you want to start from
> > where it fails, but inside tcf_action_put_many() it starts from 0
> > to TCA_ACT_MAX_PRIO, out-of-bound access at least?
>
> Actions array is declared to be TCA_ACT_MAX_PRIO+1 in size, and
Declaration doesn't matter at all, functions see it as a pure pointer
once you pass it as an argument.
> initialized to NULL pointers. In loop inside tcf_action_put_many() there
> are two checks: One is that index is less than TCA_ACT_MAX_PRIO and
> another one that pointer is not NULL. In this case I rely on extra NULL
> pointer at the end of actions array to prevent out-of-bound access.
True, but you pass &actions[acts_deleted] as the start of the array,
so inside it would be:
&actions[acts_deleted][0]...&actions[acts_deleted][MAX_PRIO]
So, the overall of the result is:
actions[acts_deleted]...actions[acts_deleted + MAX_PRIO]
You have out-of-bound access when acts_deleted > 1.
And if acts_deleted == MAX_PRIO-1, then you don't have any
NULL pointer to rely on.
^ permalink raw reply
* Re: [PATCH ethtool 2/3] ethtool: Add support for WAKE_FILTER (WoL using filters)
From: Florian Fainelli @ 2018-08-08 18:25 UTC (permalink / raw)
To: netdev; +Cc: linville, andrew, davem
In-Reply-To: <20180808182211.24921-3-f.fainelli@gmail.com>
On 08/08/2018 11:22 AM, Florian Fainelli wrote:
> Add a new character 'f' which can be used to configure an Ethernet
> controller to support Wake-on-LAN using filters programmed with the
> ethtool::rxnfc and the special action -2 (wake-up filter). This is
> useful in particular in the context of devices that must support wake-up
> on more complex patterns such as multicast DNS packets.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> ethtool.8.in | 4 +++-
> ethtool.c | 5 +++++
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/ethtool.8.in b/ethtool.8.in
> index 0a366aa536ae..97c7330fd373 100644
> --- a/ethtool.8.in
> +++ b/ethtool.8.in
> @@ -58,7 +58,7 @@
> .\"
> .\" \(*WO - wol flags
> .\"
> -.ds WO \fBp\fP|\fBu\fP|\fBm\fP|\fBb\fP|\fBa\fP|\fBg\fP|\fBs\fP|\fBd\fP...
> +.ds WO \fBp\fP|\fBu\fP|\fBm\fP|\fBb\fP|\fBa\fP|\fBg\fP|\fBs\fP|\fBf|\fBd\fP...
> .\"
> .\" \(*FL - flow type values
> .\"
> @@ -679,6 +679,7 @@ b Wake on broadcast messages
> a Wake on ARP
> g Wake on MagicPacket\[tm]
> s Enable SecureOn\[tm] password for MagicPacket\[tm]
> +f Wake on filter(s)
> d T{
> Disable (wake on nothing). This option clears all previous options.
> T}
> @@ -870,6 +871,7 @@ Specifies the Rx queue to send packets to, or some other action.
> nokeep;
> lB l.
> -1 Drop the matched flow
> +-2 Use the matched flow as a Wake-on-LAN filter
Humm, this hunk belongs in patch #3, I will re-submit that series after
you give me some feedback. Thanks!
--
Florian
^ permalink raw reply
* [PATCH iproute2-next] Add SKB Priority qdisc support in tc(8)
From: Nishanth Devarajan @ 2018-08-08 18:24 UTC (permalink / raw)
To: stephen, dsahern; +Cc: netdev, doucette, michel
sch_skbprio is a qdisc that prioritizes packets according to their skb->priority
field. Under congestion, it drops already-enqueued lower priority packets to
make space available for higher priority packets. Skbprio was conceived as a
solution for denial-of-service defenses that need to route packets with
different priorities as a means to overcome DoS attacks.
Signed-off-by: Nishanth Devarajan <ndev2021@gmail.com>
Reviewed-by: Michel Machado <michel@digirati.com.br>
---
include/uapi/linux/pkt_sched.h | 7 ++++
man/man8/tc-skbprio.8 | 70 ++++++++++++++++++++++++++++++++++++
tc/Makefile | 1 +
tc/q_skbprio.c | 81 ++++++++++++++++++++++++++++++++++++++++++
4 files changed, 159 insertions(+)
create mode 100644 man/man8/tc-skbprio.8
create mode 100644 tc/q_skbprio.c
diff --git a/include/uapi/linux/pkt_sched.h b/include/uapi/linux/pkt_sched.h
index 37b5096..81af99e 100644
--- a/include/uapi/linux/pkt_sched.h
+++ b/include/uapi/linux/pkt_sched.h
@@ -124,6 +124,12 @@ struct tc_fifo_qopt {
__u32 limit; /* Queue length: bytes for bfifo, packets for pfifo */
};
+/* SKBPRIO section */
+
+struct tc_skbprio_qopt {
+ __u32 limit; /* Queue length in packets. */
+};
+
/* PRIO section */
#define TCQ_PRIO_BANDS 16
@@ -256,6 +262,7 @@ struct tc_red_qopt {
#define TC_RED_ECN 1
#define TC_RED_HARDDROP 2
#define TC_RED_ADAPTATIVE 4
+#define TC_RED_OFFLOADED 8
};
struct tc_red_xstats {
diff --git a/man/man8/tc-skbprio.8 b/man/man8/tc-skbprio.8
new file mode 100644
index 0000000..15a8524
--- /dev/null
+++ b/man/man8/tc-skbprio.8
@@ -0,0 +1,70 @@
+.TH SKBPRIO 8 "8 August 2018" "iproute2" "Linux"
+.SH NAME
+skbprio \- SKB Priority Queue
+
+.SH SYNOPSIS
+.B tc qdisc ... add skbprio
+.B [ limit
+packets
+.B ]
+
+.SH DESCRIPTION
+SKB Priority Queue is a queueing discipline intended to prioritize
+the most important packets during a denial-of-service (
+.B DoS
+) attack. The priority of a packet is given by
+.B skb->priority
+, where a higher value places the packet closer to the exit of the queue. When
+the queue is full, the lowest priority packet in the queue is dropped to make
+room for the packet to be added if it has higher priority. If the packet to be
+added has lower priority than all packets in the queue, it is dropped.
+
+Without SKB priority queue, queue length limits must be imposed
+on individual sub-queues, and there is no straightforward way to enforce
+a global queue length limit across all priorities. SKBprio queue enforces a
+global queue length limit while not restricting the lengths of individual
+sub-queues.
+
+While SKB Priority Queue is agnostic to how
+.B skb->priority
+is assigned. A typical use case is to copy
+the 6-bit DS field of IPv4 and IPv6 packets using
+.BR tc-skbedit (8)
+. If
+.B skb->priority
+is greater or equal to 64, the priority is assumed to be 63.
+Priorities less than 64 are taken at face value.
+
+SKB Priority Queue enables routers to locally decide which
+packets to drop under a DoS attack.
+Priorities should be assigned to packets such that the higher the priority,
+the more expected behavior a source shows.
+So sources have an incentive to play by the rules.
+
+.SH ALGORITHM
+
+Skbprio maintains 64 lists (priorities go from 0 to 63).
+When a packet is enqueued, it gets inserted at the
+.B tail
+of its priority list. When a packet needs to be sent out to the network, it is
+taken from the head of the highest priority list. When the queue is full,
+the packet at the tail of the lowest priority list is dropped to serve the
+ingress packet - if it is of higher priority, otherwise the ingress packet is
+dropped. This algorithm allocates as much bandwidth as possible to high
+priority packets, while only servicing low priority packets when
+there is enough bandwidth.
+
+.SH PARAMETERS
+.TP
+limit
+Maximum queue size specified in packets. It defaults to 64.
+The range for this parameter is [0, UINT32_MAX].
+
+.SH SEE ALSO
+.BR tc-prio (8),
+.BR tc-skbedit (8)
+
+.SH AUTHORS
+Nishanth Devarajan <devarajn@uci.edu>, Michel Machado <michel@digirati.com.br>
+
+This manpage maintained by Bert Hubert <ahu@ds9a.nl>
diff --git a/tc/Makefile b/tc/Makefile
index dfd0026..7646105 100644
--- a/tc/Makefile
+++ b/tc/Makefile
@@ -71,6 +71,7 @@ TCMODULES += q_clsact.o
TCMODULES += e_bpf.o
TCMODULES += f_matchall.o
TCMODULES += q_cbs.o
+TCMODULES += q_skbprio.o
TCSO :=
ifeq ($(TC_CONFIG_ATM),y)
diff --git a/tc/q_skbprio.c b/tc/q_skbprio.c
new file mode 100644
index 0000000..a2a5077
--- /dev/null
+++ b/tc/q_skbprio.c
@@ -0,0 +1,81 @@
+/*
+ * q_skbprio.c SKB PRIORITY QUEUE.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Nishanth Devarajan, <ndev_2021@gmail.com>
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <syslog.h>
+#include <fcntl.h>
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
+#include <string.h>
+
+#include "utils.h"
+#include "tc_util.h"
+
+static void explain(void)
+{
+ fprintf(stderr, "Usage: ... <skbprio> [ limit NUMBER ]\n");
+}
+
+static int skbprio_parse_opt(struct qdisc_util *qu, int argc, char **argv,
+ struct nlmsghdr *n, const char *dev)
+{
+ int ok = 0;
+ struct tc_skbprio_qopt opt = {};
+
+ while (argc > 0) {
+ if (strcmp(*argv, "limit") == 0) {
+ NEXT_ARG();
+ if (get_size(&opt.limit, *argv)) {
+ fprintf(stderr, "%s: Illegal value for \"limit\": \"%s\"\n", qu->id, *argv);
+ return -1;
+ }
+ ok++;
+ }
+ else if (strcmp(*argv, "help") == 0) {
+ explain();
+ return -1;
+ } else {
+ fprintf(stderr, "%s: unknown parameter \"%s\"\n", qu->id, *argv);
+ explain();
+ return -1;
+ }
+ argc--; argv++;
+ }
+
+ if (ok)
+ addattr_l(n, 1024, TCA_OPTIONS, &opt, sizeof(opt));
+ return 0;
+}
+
+static int skbprio_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
+{
+ struct tc_skbprio_qopt *qopt;
+
+ if (opt == NULL)
+ return 0;
+
+ if (RTA_PAYLOAD(opt) < sizeof(*qopt))
+ return -1;
+ qopt = RTA_DATA(opt);
+ fprintf(f, "limit %u ", qopt->limit);
+ return 0;
+}
+
+
+struct qdisc_util skbprio_qdisc_util = {
+ .id = "skbprio",
+ .parse_qopt = skbprio_parse_opt,
+ .print_qopt = skbprio_print_opt,
+};
--
1.9.1
^ permalink raw reply related
* [PATCH ethtool 3/3] ethtool: Add support for action value -2 (wake-up filter)
From: Florian Fainelli @ 2018-08-08 18:22 UTC (permalink / raw)
To: netdev; +Cc: linville, andrew, davem, Florian Fainelli
In-Reply-To: <20180808182211.24921-1-f.fainelli@gmail.com>
Add the ability to program special filters using ethtool::rxnfc which
are meant to be used for wake-up purposes (in conjuction with
WAKE_FILTER) using the special action value: -2 (RX_CLS_FLOW_WAKE).
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
rxclass.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/rxclass.c b/rxclass.c
index 42d122d1ed86..79972651e706 100644
--- a/rxclass.c
+++ b/rxclass.c
@@ -251,7 +251,11 @@ static void rxclass_print_nfc_rule(struct ethtool_rx_flow_spec *fsp,
if (fsp->flow_type & FLOW_RSS)
fprintf(stdout, "\tRSS Context ID: %u\n", rss_context);
- if (fsp->ring_cookie != RX_CLS_FLOW_DISC) {
+ if (fsp->ring_cookie == RX_CLS_FLOW_DISC) {
+ fprintf(stdout, "\tAction: Drop\n");
+ } else if (fsp->ring_cookie == RX_CLS_FLOW_WAKE) {
+ fprintf(stdout, "\tAction: Wake-on-LAN\n");
+ } else {
u64 vf = ethtool_get_flow_spec_ring_vf(fsp->ring_cookie);
u64 queue = ethtool_get_flow_spec_ring(fsp->ring_cookie);
@@ -266,8 +270,6 @@ static void rxclass_print_nfc_rule(struct ethtool_rx_flow_spec *fsp,
else
fprintf(stdout, "\tAction: Direct to queue %llu\n",
queue);
- } else {
- fprintf(stdout, "\tAction: Drop\n");
}
fprintf(stdout, "\n");
--
2.17.1
^ permalink raw reply related
* [PATCH ethtool 2/3] ethtool: Add support for WAKE_FILTER (WoL using filters)
From: Florian Fainelli @ 2018-08-08 18:22 UTC (permalink / raw)
To: netdev; +Cc: linville, andrew, davem, Florian Fainelli
In-Reply-To: <20180808182211.24921-1-f.fainelli@gmail.com>
Add a new character 'f' which can be used to configure an Ethernet
controller to support Wake-on-LAN using filters programmed with the
ethtool::rxnfc and the special action -2 (wake-up filter). This is
useful in particular in the context of devices that must support wake-up
on more complex patterns such as multicast DNS packets.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
ethtool.8.in | 4 +++-
ethtool.c | 5 +++++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/ethtool.8.in b/ethtool.8.in
index 0a366aa536ae..97c7330fd373 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -58,7 +58,7 @@
.\"
.\" \(*WO - wol flags
.\"
-.ds WO \fBp\fP|\fBu\fP|\fBm\fP|\fBb\fP|\fBa\fP|\fBg\fP|\fBs\fP|\fBd\fP...
+.ds WO \fBp\fP|\fBu\fP|\fBm\fP|\fBb\fP|\fBa\fP|\fBg\fP|\fBs\fP|\fBf|\fBd\fP...
.\"
.\" \(*FL - flow type values
.\"
@@ -679,6 +679,7 @@ b Wake on broadcast messages
a Wake on ARP
g Wake on MagicPacket\[tm]
s Enable SecureOn\[tm] password for MagicPacket\[tm]
+f Wake on filter(s)
d T{
Disable (wake on nothing). This option clears all previous options.
T}
@@ -870,6 +871,7 @@ Specifies the Rx queue to send packets to, or some other action.
nokeep;
lB l.
-1 Drop the matched flow
+-2 Use the matched flow as a Wake-on-LAN filter
0 or higher Rx queue to route the flow
.TE
.TP
diff --git a/ethtool.c b/ethtool.c
index fb93ae898312..aa2bbe9e4c65 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -931,6 +931,9 @@ static int parse_wolopts(char *optstr, u32 *data)
case 's':
*data |= WAKE_MAGICSECURE;
break;
+ case 'f':
+ *data |= WAKE_FILTER;
+ break;
case 'd':
*data = 0;
break;
@@ -964,6 +967,8 @@ static char *unparse_wolopts(int wolopts)
*p++ = 'g';
if (wolopts & WAKE_MAGICSECURE)
*p++ = 's';
+ if (wolopts & WAKE_FILTER)
+ *p++ = 'f';
} else {
*p = 'd';
}
--
2.17.1
^ permalink raw reply related
* [PATCH ethtool 1/3] ethtool-copy.h: sync with net-next
From: Florian Fainelli @ 2018-08-08 18:22 UTC (permalink / raw)
To: netdev; +Cc: linville, andrew, davem, Florian Fainelli
In-Reply-To: <20180808182211.24921-1-f.fainelli@gmail.com>
This covers kernel changes up to commit 6cfef793b558:
ethtool: Add WAKE_FILTER and RX_CLS_FLOW_WAKE
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
ethtool-copy.h | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 8cc61e9ab40b..6bfbb85f9402 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -215,12 +215,16 @@ struct ethtool_value {
__u32 data;
};
+#define PFC_STORM_PREVENTION_AUTO 0xffff
+#define PFC_STORM_PREVENTION_DISABLE 0
+
enum tunable_id {
ETHTOOL_ID_UNSPEC,
ETHTOOL_RX_COPYBREAK,
ETHTOOL_TX_COPYBREAK,
+ ETHTOOL_PFC_PREVENTION_TOUT, /* timeout in msecs */
/*
- * Add your fresh new tubale attribute above and remember to update
+ * Add your fresh new tunable attribute above and remember to update
* tunable_strings[] in net/core/ethtool.c
*/
__ETHTOOL_TUNABLE_COUNT,
@@ -864,7 +868,8 @@ struct ethtool_flow_ext {
* includes the %FLOW_EXT or %FLOW_MAC_EXT flag
* (see &struct ethtool_flow_ext description).
* @ring_cookie: RX ring/queue index to deliver to, or %RX_CLS_FLOW_DISC
- * if packets should be discarded
+ * if packets should be discarded, or %RX_CLS_FLOW_WAKE if the
+ * packets should be used for Wake-on-LAN with %WAKE_FILTER
* @location: Location of rule in the table. Locations must be
* numbered such that a flow matching multiple rules will be
* classified according to the first (lowest numbered) rule.
@@ -896,13 +901,13 @@ struct ethtool_rx_flow_spec {
static __inline__ __u64 ethtool_get_flow_spec_ring(__u64 ring_cookie)
{
return ETHTOOL_RX_FLOW_SPEC_RING & ring_cookie;
-};
+}
static __inline__ __u64 ethtool_get_flow_spec_ring_vf(__u64 ring_cookie)
{
return (ETHTOOL_RX_FLOW_SPEC_RING_VF & ring_cookie) >>
ETHTOOL_RX_FLOW_SPEC_RING_VF_OFF;
-};
+}
/**
* struct ethtool_rxnfc - command to get or set RX flow classification rules
@@ -1628,6 +1633,7 @@ static __inline__ int ethtool_validate_duplex(__u8 duplex)
#define WAKE_ARP (1 << 4)
#define WAKE_MAGIC (1 << 5)
#define WAKE_MAGICSECURE (1 << 6) /* only meaningful if WAKE_MAGIC */
+#define WAKE_FILTER (1 << 7)
/* L2-L4 network traffic flow types */
#define TCP_V4_FLOW 0x01 /* hash or spec (tcp_ip4_spec) */
@@ -1665,6 +1671,7 @@ static __inline__ int ethtool_validate_duplex(__u8 duplex)
#define RXH_DISCARD (1 << 31)
#define RX_CLS_FLOW_DISC 0xffffffffffffffffULL
+#define RX_CLS_FLOW_WAKE 0xfffffffffffffffeULL
/* Special RX classification rule insert location values */
#define RX_CLS_LOC_SPECIAL 0x80000000 /* flag */
--
2.17.1
^ permalink raw reply related
* [PATCH ethtool 0/3] ethtool: Wake-on-LAN using filters
From: Florian Fainelli @ 2018-08-08 18:22 UTC (permalink / raw)
To: netdev; +Cc: linville, andrew, davem, Florian Fainelli
Hi John,
This patch series syncs up ethtool-copy.h to get the new definitions
required for supporting wake-on-LAN using filters: WAKE_FILTER and
RX_CLS_FLOW_WAKE and then updates the rxclass.c code to allow us to
specify action -2 (RX_CLS_FLOW_WAKE).
Let me know if you would like this to be done differently.
Thanks!
Florian Fainelli (3):
ethtool-copy.h: sync with net-next
ethtool: Add support for WAKE_FILTER (WoL using filters)
ethtool: Add support for action value -2 (wake-up filter)
ethtool-copy.h | 15 +++++++++++----
ethtool.8.in | 4 +++-
ethtool.c | 5 +++++
rxclass.c | 8 +++++---
4 files changed, 24 insertions(+), 8 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [RFC net-next 00/15] net: A socket API for LoRa
From: Alan Cox @ 2018-08-08 20:36 UTC (permalink / raw)
To: Andreas Färber
Cc: Michal Kubeček, Konstantin Böhm, Pieter Robyns, contact,
Ken Yu, Michael Röder, Stefan Schmidt, Rob Herring, lora,
Alexander Graf, Jan Jongboom, Janus Piwek, Jon Ortego,
Jian-Hong Pan, devicetree, Jiri Pirko, Hasnain Virk,
Daniele Comel, Marcel Holtmann, Mark Brown, Dollar Chen,
Brian Ray, linux-arm-kernel
In-Reply-To: <92ee4016-1da9-826b-3674-b2d604a64848@suse.de>
On Sun, 5 Aug 2018 02:11:25 +0200
Andreas Färber <afaerber@suse.de> wrote:
> Hi Jian-Hong,
>
> Am 03.07.2018 um 17:11 schrieb Jian-Hong Pan:
> > 2018-07-01 19:07 GMT+08:00 Andreas Färber <afaerber@suse.de>:
> >> 2) PF_LORA is used with SOCK_DGRAM here. The assumption is that RAW mode
> >> would be DGRAM plus preamble plus optional checksum.
> >
> > Is the preamble added by the hardware itself here or software here?
>
> That depends on the driver. For SX127x and any SX127x based modules it
> is added by hardware and a SOCK_RAW seems impossible. If you were to use
> some SDR hardware, it would need to be done by software and might either
> be done in the device driver for SOCK_DGRAM or by user with a SOCK_RAW.
> Right now I don't see a practical use case for the latter. (CC Pieter)
For TCP/IP a SOCK_RAW is a socket with raw IP level access. It doesn't
deal in IP headers and unless you ask it also does chunks of IP header
stuff for you.
SOCK_PACKET is the truely raw interface and even then it's rawness is
bounded. You can't for example talk truely raw wifi bit streams, and for
ethernet you get to generate MAC headers but not preambles etc.
> LoRa radio channels being half-duplex, we'd need to stop receiving in
> ndo_start_xmit and re-start receiving in the TX interrupt handler AFAIU.
> Yes, it's ugly - one reason I haven't implemented RX in sx1276 yet.
Why - the signal is still floating around in the air, you can't unhear it
at the antenna. If a given piece of hardware needs to flip between RX
and TX mode then it should be handled by that driver.
(Some ancient ethernet cards do this btw.. they can't listen and transmit
at the same time)
> > - We can have a pre-defined table according to LoRaWAN Regional Parameters.
> > - Device driver declares the hardware's capability, for example
> > frequency, TX power. And then registers as a LoRaWAN compatible
> > device.
>
> That sounds like a layering violation. We rather need to expose all
> these tunable parameters individually at the LoRa layer, allowing the
> LoRaWAN layer to configure them as it pleases. Not the other direction.
> That still leaves my above question 4) open of how to implement each.
Wifi already has the general policy database for the various existing
protocols. Please take a look at the CRDA agent and how it hooks into
wireless.It might need to some tweaking but it would be odd to have
different configuration schemes for different wifi protocols.
> The use case I have in mind is this: User A opens a LoRaWAN socket and
> using maclorawan sends a packet P1. Here the LoRaWAN Regional Parameters
> and LoRaWAN Sync Word need to be applied.
> User B then opens a pure LoRa socket and transmits a packet P1' with
> different Sync Word, SF, BW, CR, etc.
> Afterwards user A wants to send another packet P2 via LoRaWAN - this
> needs to use the same LoRaWAN settings as before, not those used for
> LoRa in between. Therefore I was thinking about socket-level options, as
> netlink operations would be device-wide, with undesired side-effects.
Agreed
> Obviously in that scenario not both users can receive at the same time.
That's a hardware question. Imagine a software defined radio. If your
limitation wouldn't exist in a pure software defined radio then it's
almost certainly a device level detal.
> interface but cleanly distinguished as ETH_P_GFSK or something.
> For example, the Chistera Pi HAT has both an RFM95W and an RFM22 module.
Agreed if you can flip per packet.
> The next question arising is how the user would create such an skb. Just
> like I was hesitant about PF_LORAWAN originally, I'd like to avoid
> polluting the PF_ number space for each of these. Maybe have one PF_FSK
> as equivalent to PF_LORA and then have either a socket option or
> sockaddr field to select the modulation variants? Not sure how exactly
> those others differ from each other, that's why I tried to postpone the
> FSK topic and to focus on LoRa first - b) below.
>
> At this point we could also argue whether we need a PF_LORA at all or
> rather just some generic PF_RADIO with lots of options stored in its
> sockaddr.
What matters most is mux/demux.
If you've got something listening to data but without the structure
needed to identify multiple listeners and split out the data meaningfully
to those listeners according to parts of the packet then you've got no
reason to make it a protocol just use SOCK_PACKET and if need be BPF.
The reason we have a socket layer not /dev/ethernet0 is that it's
meaningful to divide messages up into flows, and to partition those flows
securely amongst multiple consumers/generators.
Alan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH net-next v1 1/1] net/tls: Combined memory allocation for decryption request
From: Vakul Garg @ 2018-08-08 18:08 UTC (permalink / raw)
To: Dave Watson
Cc: netdev@vger.kernel.org, borisp@mellanox.com, aviadye@mellanox.com,
davem@davemloft.net
In-Reply-To: <20180808170716.GB82808@davejwatson-mba.local>
> -----Original Message-----
> From: Dave Watson [mailto:davejwatson@fb.com]
> Sent: Wednesday, August 8, 2018 10:37 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 v1 1/1] net/tls: Combined memory allocation
> for decryption request
>
> On 08/08/18 06:36 PM, Vakul Garg wrote:
> > For preparing decryption request, several memory chunks are required
> > (aead_req, sgin, sgout, iv, aad). For submitting the decrypt request
> > to an accelerator, it is required that the buffers which are read by
> > the accelerator must be dma-able and not come from stack. The buffers
> > for aad and iv can be separately kmalloced each, but it is inefficient.
> > This patch does a combined allocation for preparing decryption request
> > and then segments into aead_req || sgin || sgout || iv || aad.
> >
> > Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
> > ---
> > + n_sgout = sg_nents(out_sg);
> > +
> > + n_sgin = skb_nsg(skb, rxm->offset + tls_ctx->rx.prepend_size,
> > + rxm->full_len - tls_ctx->rx.prepend_size);
> > + } else {
> > +no_zerocopy:
>
> label is unused now
Thanks for reviewing the patch.
I wish compiler could have warned about unused label..
I have submitted 'v2'.
^ permalink raw reply
* [PATCH net-next v2 1/1] net/tls: Combined memory allocation for decryption request
From: Vakul Garg @ 2018-08-08 23:26 UTC (permalink / raw)
To: netdev; +Cc: borisp, aviadye, davejwatson, davem, Vakul Garg
In-Reply-To: <20180808232623.18075-1-vakul.garg@nxp.com>
For preparing decryption request, several memory chunks are required
(aead_req, sgin, sgout, iv, aad). For submitting the decrypt request to
an accelerator, it is required that the buffers which are read by the
accelerator must be dma-able and not come from stack. The buffers for
aad and iv can be separately kmalloced each, but it is inefficient.
This patch does a combined allocation for preparing decryption request
and then segments into aead_req || sgin || sgout || iv || aad.
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
This patch needs to be applied over Doron Roberts-Kedes's patch.
net/tls: Calculate nsg for zerocopy path without skb_cow_data.
Changes since patch v1:
- Removed unused label 'no_zerocopy'
include/net/tls.h | 4 -
net/tls/tls_sw.c | 257 ++++++++++++++++++++++++++++++------------------------
2 files changed, 145 insertions(+), 116 deletions(-)
diff --git a/include/net/tls.h b/include/net/tls.h
index d8b3b6578c01..d5c683e8bb22 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -124,10 +124,6 @@ struct tls_sw_context_rx {
struct sk_buff *recv_pkt;
u8 control;
bool decrypted;
-
- char rx_aad_ciphertext[TLS_AAD_SPACE_SIZE];
- char rx_aad_plaintext[TLS_AAD_SPACE_SIZE];
-
};
struct tls_record_info {
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 55eb04415bb3..13e365011347 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -122,19 +122,13 @@ static int tls_do_decryption(struct sock *sk,
struct scatterlist *sgout,
char *iv_recv,
size_t data_len,
- struct sk_buff *skb,
- gfp_t flags)
+ struct aead_request *aead_req)
{
struct tls_context *tls_ctx = tls_get_ctx(sk);
struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
- struct aead_request *aead_req;
-
int ret;
- aead_req = aead_request_alloc(ctx->aead_recv, flags);
- if (!aead_req)
- return -ENOMEM;
-
+ aead_request_set_tfm(aead_req, ctx->aead_recv);
aead_request_set_ad(aead_req, TLS_AAD_SPACE_SIZE);
aead_request_set_crypt(aead_req, sgin, sgout,
data_len + tls_ctx->rx.tag_size,
@@ -143,8 +137,6 @@ static int tls_do_decryption(struct sock *sk,
crypto_req_done, &ctx->async_wait);
ret = crypto_wait_req(crypto_aead_decrypt(aead_req), &ctx->async_wait);
-
- aead_request_free(aead_req);
return ret;
}
@@ -731,8 +723,135 @@ static struct sk_buff *tls_wait_data(struct sock *sk, int flags,
return skb;
}
+/* This function decrypts the input skb into either out_iov or in out_sg
+ * or in skb buffers itself. The input parameter 'zc' indicates if
+ * zero-copy mode needs to be tried or not. With zero-copy mode, either
+ * out_iov or out_sg must be non-NULL. In case both out_iov and out_sg are
+ * NULL, then the decryption happens inside skb buffers itself, i.e.
+ * zero-copy gets disabled and 'zc' is updated.
+ */
+
+static int decrypt_internal(struct sock *sk, struct sk_buff *skb,
+ struct iov_iter *out_iov,
+ struct scatterlist *out_sg,
+ int *chunk, bool *zc)
+{
+ struct tls_context *tls_ctx = tls_get_ctx(sk);
+ struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
+ struct strp_msg *rxm = strp_msg(skb);
+ int n_sgin, n_sgout, nsg, mem_size, aead_size, err, pages = 0;
+ struct aead_request *aead_req;
+ struct sk_buff *unused;
+ u8 *aad, *iv, *mem = NULL;
+ struct scatterlist *sgin = NULL;
+ struct scatterlist *sgout = NULL;
+ const int data_len = rxm->full_len - tls_ctx->rx.overhead_size;
+
+ if (*zc && (out_iov || out_sg)) {
+ if (out_iov)
+ n_sgout = iov_iter_npages(out_iov, INT_MAX) + 1;
+ else
+ n_sgout = sg_nents(out_sg);
+
+ n_sgin = skb_nsg(skb, rxm->offset + tls_ctx->rx.prepend_size,
+ rxm->full_len - tls_ctx->rx.prepend_size);
+ } else {
+ n_sgout = 0;
+ *zc = false;
+ n_sgin = skb_cow_data(skb, 0, &unused);
+ }
+
+ if (n_sgin < 1)
+ return -EBADMSG;
+
+ /* Increment to accommodate AAD */
+ n_sgin = n_sgin + 1;
+
+ nsg = n_sgin + n_sgout;
+
+ aead_size = sizeof(*aead_req) + crypto_aead_reqsize(ctx->aead_recv);
+ mem_size = aead_size + (nsg * sizeof(struct scatterlist));
+ mem_size = mem_size + TLS_AAD_SPACE_SIZE;
+ mem_size = mem_size + crypto_aead_ivsize(ctx->aead_recv);
+
+ /* Allocate a single block of memory which contains
+ * aead_req || sgin[] || sgout[] || aad || iv.
+ * This order achieves correct alignment for aead_req, sgin, sgout.
+ */
+ mem = kmalloc(mem_size, sk->sk_allocation);
+ if (!mem)
+ return -ENOMEM;
+
+ /* Segment the allocated memory */
+ aead_req = (struct aead_request *)mem;
+ sgin = (struct scatterlist *)(mem + aead_size);
+ sgout = sgin + n_sgin;
+ aad = (u8 *)(sgout + n_sgout);
+ iv = aad + TLS_AAD_SPACE_SIZE;
+
+ /* Prepare IV */
+ err = skb_copy_bits(skb, rxm->offset + TLS_HEADER_SIZE,
+ iv + TLS_CIPHER_AES_GCM_128_SALT_SIZE,
+ tls_ctx->rx.iv_size);
+ if (err < 0) {
+ kfree(mem);
+ return err;
+ }
+ memcpy(iv, tls_ctx->rx.iv, TLS_CIPHER_AES_GCM_128_SALT_SIZE);
+
+ /* Prepare AAD */
+ tls_make_aad(aad, rxm->full_len - tls_ctx->rx.overhead_size,
+ tls_ctx->rx.rec_seq, tls_ctx->rx.rec_seq_size,
+ ctx->control);
+
+ /* Prepare sgin */
+ sg_init_table(sgin, n_sgin);
+ sg_set_buf(&sgin[0], aad, TLS_AAD_SPACE_SIZE);
+ err = skb_to_sgvec(skb, &sgin[1],
+ rxm->offset + tls_ctx->rx.prepend_size,
+ rxm->full_len - tls_ctx->rx.prepend_size);
+ if (err < 0) {
+ kfree(mem);
+ return err;
+ }
+
+ if (n_sgout) {
+ if (out_iov) {
+ sg_init_table(sgout, n_sgout);
+ sg_set_buf(&sgout[0], aad, TLS_AAD_SPACE_SIZE);
+
+ *chunk = 0;
+ err = zerocopy_from_iter(sk, out_iov, data_len, &pages,
+ chunk, &sgout[1],
+ (n_sgout - 1), false);
+ if (err < 0)
+ goto fallback_to_reg_recv;
+ } else if (out_sg) {
+ memcpy(sgout, out_sg, n_sgout * sizeof(*sgout));
+ } else {
+ goto fallback_to_reg_recv;
+ }
+ } else {
+fallback_to_reg_recv:
+ sgout = sgin;
+ pages = 0;
+ *chunk = 0;
+ *zc = false;
+ }
+
+ /* Prepare and submit AEAD request */
+ err = tls_do_decryption(sk, sgin, sgout, iv, data_len, aead_req);
+
+ /* Release the pages in case iov was mapped to pages */
+ for (; pages > 0; pages--)
+ put_page(sg_page(&sgout[pages]));
+
+ kfree(mem);
+ return err;
+}
+
static int decrypt_skb_update(struct sock *sk, struct sk_buff *skb,
- struct scatterlist *sgout, bool *zc)
+ struct iov_iter *dest, int *chunk, bool *zc)
{
struct tls_context *tls_ctx = tls_get_ctx(sk);
struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
@@ -745,7 +864,7 @@ static int decrypt_skb_update(struct sock *sk, struct sk_buff *skb,
return err;
#endif
if (!ctx->decrypted) {
- err = decrypt_skb(sk, skb, sgout);
+ err = decrypt_internal(sk, skb, dest, NULL, chunk, zc);
if (err < 0)
return err;
} else {
@@ -764,70 +883,10 @@ static int decrypt_skb_update(struct sock *sk, struct sk_buff *skb,
int decrypt_skb(struct sock *sk, struct sk_buff *skb,
struct scatterlist *sgout)
{
- struct tls_context *tls_ctx = tls_get_ctx(sk);
- struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
- char iv[TLS_CIPHER_AES_GCM_128_SALT_SIZE + MAX_IV_SIZE];
- struct scatterlist sgin_arr[MAX_SKB_FRAGS + 2];
- struct scatterlist *sgin = &sgin_arr[0];
- struct strp_msg *rxm = strp_msg(skb);
- int ret, nsg;
- struct sk_buff *unused;
-
- ret = skb_copy_bits(skb, rxm->offset + TLS_HEADER_SIZE,
- iv + TLS_CIPHER_AES_GCM_128_SALT_SIZE,
- tls_ctx->rx.iv_size);
- if (ret < 0)
- return ret;
-
- memcpy(iv, tls_ctx->rx.iv, TLS_CIPHER_AES_GCM_128_SALT_SIZE);
- if (!sgout) {
- nsg = skb_cow_data(skb, 0, &unused);
- } else {
- nsg = skb_nsg(skb,
- rxm->offset + tls_ctx->rx.prepend_size,
- rxm->full_len - tls_ctx->rx.prepend_size);
- if (nsg <= 0)
- return nsg;
- }
-
- // We need one extra for ctx->rx_aad_ciphertext
- nsg++;
-
- if (nsg > ARRAY_SIZE(sgin_arr)) {
- sgin = kmalloc_array(nsg, sizeof(*sgin), sk->sk_allocation);
- if (!sgin)
- return -ENOMEM;
- }
-
- if (!sgout)
- sgout = sgin;
-
- sg_init_table(sgin, nsg);
- sg_set_buf(&sgin[0], ctx->rx_aad_ciphertext, TLS_AAD_SPACE_SIZE);
-
- nsg = skb_to_sgvec(skb, &sgin[1],
- rxm->offset + tls_ctx->rx.prepend_size,
- rxm->full_len - tls_ctx->rx.prepend_size);
- if (nsg < 0) {
- ret = nsg;
- goto out;
- }
-
- tls_make_aad(ctx->rx_aad_ciphertext,
- rxm->full_len - tls_ctx->rx.overhead_size,
- tls_ctx->rx.rec_seq,
- tls_ctx->rx.rec_seq_size,
- ctx->control);
-
- ret = tls_do_decryption(sk, sgin, sgout, iv,
- rxm->full_len - tls_ctx->rx.overhead_size,
- skb, sk->sk_allocation);
-
-out:
- if (sgin != &sgin_arr[0])
- kfree(sgin);
+ bool zc = true;
+ int chunk;
- return ret;
+ return decrypt_internal(sk, skb, NULL, sgout, &chunk, &zc);
}
static bool tls_sw_advance_skb(struct sock *sk, struct sk_buff *skb,
@@ -906,43 +965,17 @@ int tls_sw_recvmsg(struct sock *sk,
}
if (!ctx->decrypted) {
- int page_count;
- int to_copy;
-
- page_count = iov_iter_npages(&msg->msg_iter,
- MAX_SKB_FRAGS);
- to_copy = rxm->full_len - tls_ctx->rx.overhead_size;
- if (!is_kvec && to_copy <= len && page_count < MAX_SKB_FRAGS &&
- likely(!(flags & MSG_PEEK))) {
- struct scatterlist sgin[MAX_SKB_FRAGS + 1];
- int pages = 0;
+ int to_copy = rxm->full_len - tls_ctx->rx.overhead_size;
+ if (!is_kvec && to_copy <= len &&
+ likely(!(flags & MSG_PEEK)))
zc = true;
- sg_init_table(sgin, MAX_SKB_FRAGS + 1);
- sg_set_buf(&sgin[0], ctx->rx_aad_plaintext,
- TLS_AAD_SPACE_SIZE);
-
- err = zerocopy_from_iter(sk, &msg->msg_iter,
- to_copy, &pages,
- &chunk, &sgin[1],
- MAX_SKB_FRAGS, false);
- if (err < 0)
- goto fallback_to_reg_recv;
-
- err = decrypt_skb_update(sk, skb, sgin, &zc);
- for (; pages > 0; pages--)
- put_page(sg_page(&sgin[pages]));
- if (err < 0) {
- tls_err_abort(sk, EBADMSG);
- goto recv_end;
- }
- } else {
-fallback_to_reg_recv:
- err = decrypt_skb_update(sk, skb, NULL, &zc);
- if (err < 0) {
- tls_err_abort(sk, EBADMSG);
- goto recv_end;
- }
+
+ err = decrypt_skb_update(sk, skb, &msg->msg_iter,
+ &chunk, &zc);
+ if (err < 0) {
+ tls_err_abort(sk, EBADMSG);
+ goto recv_end;
}
ctx->decrypted = true;
}
@@ -993,7 +1026,7 @@ ssize_t tls_sw_splice_read(struct socket *sock, loff_t *ppos,
int err = 0;
long timeo;
int chunk;
- bool zc;
+ bool zc = false;
lock_sock(sk);
@@ -1010,7 +1043,7 @@ ssize_t tls_sw_splice_read(struct socket *sock, loff_t *ppos,
}
if (!ctx->decrypted) {
- err = decrypt_skb_update(sk, skb, NULL, &zc);
+ err = decrypt_skb_update(sk, skb, NULL, &chunk, &zc);
if (err < 0) {
tls_err_abort(sk, EBADMSG);
--
2.13.6
^ permalink raw reply related
* [PATCH net-next v2 0/1] net/tls: Combined memory allocation for decryption request
From: Vakul Garg @ 2018-08-08 23:26 UTC (permalink / raw)
To: netdev; +Cc: borisp, aviadye, davejwatson, davem, Vakul Garg
This patch does a combined memory allocation from heap for scatterlists,
aead_request, aad and iv for the tls record decryption path. In present
code, aead_request is allocated from heap, scatterlists on a conditional
basis are allocated on heap or on stack. This is inefficient as it may
requires multiple kmalloc/kfree.
The initialization vector passed in cryption request is allocated on
stack. This is a problem since the stack memory is not dma-able from
crypto accelerators.
Doing one combined memory allocation for each decryption request fixes
both the above issues. It also paves a way to be able to submit multiple
async decryption requests while the previous one is pending i.e. being
processed or queued.
This patch needs to be applied over Doron Roberts-Kedes's patch.
net/tls: Calculate nsg for zerocopy path without skb_cow_data.
Vakul Garg (1):
net/tls: Combined memory allocation for decryption request
include/net/tls.h | 4 -
net/tls/tls_sw.c | 257 ++++++++++++++++++++++++++++++------------------------
2 files changed, 145 insertions(+), 116 deletions(-)
--
2.13.6
^ permalink raw reply
* Re: [PATCH 28/28] eeprom: at24: kill at24_platform_data
From: Andy Shevchenko @ 2018-08-08 18:03 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <20180808153150.23444-29-brgl@bgdev.pl>
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> There are no more users of at24_platform_data. Remove the relevant
> header and modify the driver code to not use it anymore.
>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
If you want me to test this on Intel Galileo Gen 2 board, give me a
public tree from where I can pull.
Thanks.
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> MAINTAINERS | 1 -
> drivers/misc/eeprom/at24.c | 127 +++++++++++++----------------
> include/linux/platform_data/at24.h | 60 --------------
> 3 files changed, 57 insertions(+), 131 deletions(-)
> delete mode 100644 include/linux/platform_data/at24.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7cebd5bba8a8..8eb87a3548f8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2328,7 +2328,6 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
> S: Maintained
> F: Documentation/devicetree/bindings/eeprom/at24.txt
> F: drivers/misc/eeprom/at24.c
> -F: include/linux/platform_data/at24.h
>
> ATA OVER ETHERNET (AOE) DRIVER
> M: "Ed L. Cashin" <ed.cashin@acm.org>
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index f5cc517d1131..93642b4b47c5 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -22,10 +22,24 @@
> #include <linux/i2c.h>
> #include <linux/nvmem-provider.h>
> #include <linux/regmap.h>
> -#include <linux/platform_data/at24.h>
> #include <linux/pm_runtime.h>
> #include <linux/gpio/consumer.h>
>
> +/* Address pointer is 16 bit. */
> +#define AT24_FLAG_ADDR16 BIT(7)
> +/* sysfs-entry will be read-only. */
> +#define AT24_FLAG_READONLY BIT(6)
> +/* sysfs-entry will be world-readable. */
> +#define AT24_FLAG_IRUGO BIT(5)
> +/* Take always 8 addresses (24c00). */
> +#define AT24_FLAG_TAKE8ADDR BIT(4)
> +/* Factory-programmed serial number. */
> +#define AT24_FLAG_SERIAL BIT(3)
> +/* Factory-programmed mac address. */
> +#define AT24_FLAG_MAC BIT(2)
> +/* Does not auto-rollover reads to the next slave address. */
> +#define AT24_FLAG_NO_RDROL BIT(1)
> +
> /*
> * I2C EEPROMs from most vendors are inexpensive and mostly interchangeable.
> * Differences between different vendor product lines (like Atmel AT24C or
> @@ -124,10 +138,6 @@ MODULE_PARM_DESC(at24_write_timeout, "Time (in ms) to try writes (default 25)");
> usleep_range(1000, 1500), op_time = jiffies)
>
> struct at24_chip_data {
> - /*
> - * these fields mirror their equivalents in
> - * struct at24_platform_data
> - */
> u32 byte_len;
> u8 flags;
> };
> @@ -467,46 +477,11 @@ static int at24_write(void *priv, unsigned int off, void *val, size_t count)
> return 0;
> }
>
> -static void at24_properties_to_pdata(struct device *dev,
> - struct at24_platform_data *chip)
> -{
> - int err;
> - u32 val;
> -
> - if (device_property_present(dev, "read-only"))
> - chip->flags |= AT24_FLAG_READONLY;
> - if (device_property_present(dev, "no-read-rollover"))
> - chip->flags |= AT24_FLAG_NO_RDROL;
> -
> - err = device_property_read_u32(dev, "size", &val);
> - if (!err)
> - chip->byte_len = val;
> -
> - err = device_property_read_u32(dev, "pagesize", &val);
> - if (!err) {
> - chip->page_size = val;
> - } else {
> - /*
> - * This is slow, but we can't know all eeproms, so we better
> - * play safe. Specifying custom eeprom-types via platform_data
> - * is recommended anyhow.
> - */
> - chip->page_size = 1;
> - }
> -}
> -
> -static int at24_get_pdata(struct device *dev, struct at24_platform_data *pdata)
> +static const struct at24_chip_data *at24_get_chip_data(struct device *dev)
> {
> struct device_node *of_node = dev->of_node;
> const struct at24_chip_data *cdata;
> const struct i2c_device_id *id;
> - struct at24_platform_data *pd;
> -
> - pd = dev_get_platdata(dev);
> - if (pd) {
> - memcpy(pdata, pd, sizeof(*pdata));
> - return 0;
> - }
>
> id = i2c_match_id(at24_ids, to_i2c_client(dev));
>
> @@ -523,13 +498,9 @@ static int at24_get_pdata(struct device *dev, struct at24_platform_data *pdata)
> cdata = acpi_device_get_match_data(dev);
>
> if (!cdata)
> - return -ENODEV;
> + return ERR_PTR(-ENODEV);
>
> - pdata->byte_len = cdata->byte_len;
> - pdata->flags = cdata->flags;
> - at24_properties_to_pdata(dev, pdata);
> -
> - return 0;
> + return cdata;
> }
>
> static void at24_remove_dummy_clients(struct at24_data *at24)
> @@ -598,8 +569,9 @@ static int at24_probe(struct i2c_client *client)
> {
> struct regmap_config regmap_config = { };
> struct nvmem_config nvmem_config = { };
> - struct at24_platform_data pdata = { };
> + const struct at24_chip_data *cdata;
> struct device *dev = &client->dev;
> + u32 byte_len, page_size, flags;
> bool i2c_fn_i2c, i2c_fn_block;
> unsigned int i, num_addresses;
> struct at24_data *at24;
> @@ -613,35 +585,54 @@ static int at24_probe(struct i2c_client *client)
> i2c_fn_block = i2c_check_functionality(client->adapter,
> I2C_FUNC_SMBUS_WRITE_I2C_BLOCK);
>
> - err = at24_get_pdata(dev, &pdata);
> + cdata = at24_get_chip_data(dev);
> + if (IS_ERR(cdata))
> + return PTR_ERR(cdata);
> +
> + err = device_property_read_u32(dev, "pagesize", &page_size);
> + if (err)
> + /*
> + * This is slow, but we can't know all eeproms, so we better
> + * play safe. Specifying custom eeprom-types via platform_data
> + * is recommended anyhow.
> + */
> + page_size = 1;
> +
> + flags = cdata->flags;
> + if (device_property_present(dev, "read-only"))
> + flags |= AT24_FLAG_READONLY;
> + if (device_property_present(dev, "no-read-rollover"))
> + flags |= AT24_FLAG_NO_RDROL;
> +
> + err = device_property_read_u32(dev, "size", &byte_len);
> if (err)
> - return err;
> + byte_len = cdata->byte_len;
>
> if (!i2c_fn_i2c && !i2c_fn_block)
> - pdata.page_size = 1;
> + page_size = 1;
>
> - if (!pdata.page_size) {
> + if (!page_size) {
> dev_err(dev, "page_size must not be 0!\n");
> return -EINVAL;
> }
>
> - if (!is_power_of_2(pdata.page_size))
> + if (!is_power_of_2(page_size))
> dev_warn(dev, "page_size looks suspicious (no power of 2)!\n");
>
> - if (pdata.flags & AT24_FLAG_TAKE8ADDR)
> + if (flags & AT24_FLAG_TAKE8ADDR)
> num_addresses = 8;
> else
> - num_addresses = DIV_ROUND_UP(pdata.byte_len,
> - (pdata.flags & AT24_FLAG_ADDR16) ? 65536 : 256);
> + num_addresses = DIV_ROUND_UP(byte_len,
> + (flags & AT24_FLAG_ADDR16) ? 65536 : 256);
>
> - if ((pdata.flags & AT24_FLAG_SERIAL) && (pdata.flags & AT24_FLAG_MAC)) {
> + if ((flags & AT24_FLAG_SERIAL) && (flags & AT24_FLAG_MAC)) {
> dev_err(dev,
> "invalid device data - cannot have both AT24_FLAG_SERIAL & AT24_FLAG_MAC.");
> return -EINVAL;
> }
>
> regmap_config.val_bits = 8;
> - regmap_config.reg_bits = (pdata.flags & AT24_FLAG_ADDR16) ? 16 : 8;
> + regmap_config.reg_bits = (flags & AT24_FLAG_ADDR16) ? 16 : 8;
> regmap_config.disable_locking = true;
>
> regmap = devm_regmap_init_i2c(client, ®map_config);
> @@ -654,11 +645,11 @@ static int at24_probe(struct i2c_client *client)
> return -ENOMEM;
>
> mutex_init(&at24->lock);
> - at24->byte_len = pdata.byte_len;
> - at24->page_size = pdata.page_size;
> - at24->flags = pdata.flags;
> + at24->byte_len = byte_len;
> + at24->page_size = page_size;
> + at24->flags = flags;
> at24->num_addresses = num_addresses;
> - at24->offset_adj = at24_get_offset_adj(pdata.flags, pdata.byte_len);
> + at24->offset_adj = at24_get_offset_adj(flags, byte_len);
> at24->client[0].client = client;
> at24->client[0].regmap = regmap;
>
> @@ -666,10 +657,10 @@ static int at24_probe(struct i2c_client *client)
> if (IS_ERR(at24->wp_gpio))
> return PTR_ERR(at24->wp_gpio);
>
> - writable = !(pdata.flags & AT24_FLAG_READONLY);
> + writable = !(flags & AT24_FLAG_READONLY);
> if (writable) {
> at24->write_max = min_t(unsigned int,
> - pdata.page_size, at24_io_limit);
> + page_size, at24_io_limit);
> if (!i2c_fn_i2c && at24->write_max > I2C_SMBUS_BLOCK_MAX)
> at24->write_max = I2C_SMBUS_BLOCK_MAX;
> }
> @@ -712,7 +703,7 @@ static int at24_probe(struct i2c_client *client)
> nvmem_config.priv = at24;
> nvmem_config.stride = 1;
> nvmem_config.word_size = 1;
> - nvmem_config.size = pdata.byte_len;
> + nvmem_config.size = byte_len;
>
> at24->nvmem = devm_nvmem_register(dev, &nvmem_config);
> if (IS_ERR(at24->nvmem)) {
> @@ -721,13 +712,9 @@ static int at24_probe(struct i2c_client *client)
> }
>
> dev_info(dev, "%u byte %s EEPROM, %s, %u bytes/write\n",
> - pdata.byte_len, client->name,
> + byte_len, client->name,
> writable ? "writable" : "read-only", at24->write_max);
>
> - /* export data to kernel code */
> - if (pdata.setup)
> - pdata.setup(at24->nvmem, pdata.context);
> -
> return 0;
>
> err_clients:
> diff --git a/include/linux/platform_data/at24.h b/include/linux/platform_data/at24.h
> deleted file mode 100644
> index 63507ff464ee..000000000000
> --- a/include/linux/platform_data/at24.h
> +++ /dev/null
> @@ -1,60 +0,0 @@
> -/*
> - * at24.h - platform_data for the at24 (generic eeprom) driver
> - * (C) Copyright 2008 by Pengutronix
> - * (C) Copyright 2012 by Wolfram Sang
> - * same license as the driver
> - */
> -
> -#ifndef _LINUX_AT24_H
> -#define _LINUX_AT24_H
> -
> -#include <linux/types.h>
> -#include <linux/nvmem-consumer.h>
> -#include <linux/bitops.h>
> -
> -/**
> - * struct at24_platform_data - data to set up at24 (generic eeprom) driver
> - * @byte_len: size of eeprom in byte
> - * @page_size: number of byte which can be written in one go
> - * @flags: tunable options, check AT24_FLAG_* defines
> - * @setup: an optional callback invoked after eeprom is probed; enables kernel
> - code to access eeprom via nvmem, see example
> - * @context: optional parameter passed to setup()
> - *
> - * If you set up a custom eeprom type, please double-check the parameters.
> - * Especially page_size needs extra care, as you risk data loss if your value
> - * is bigger than what the chip actually supports!
> - *
> - * An example in pseudo code for a setup() callback:
> - *
> - * void get_mac_addr(struct nvmem_device *nvmem, void *context)
> - * {
> - * u8 *mac_addr = ethernet_pdata->mac_addr;
> - * off_t offset = context;
> - *
> - * // Read MAC addr from EEPROM
> - * if (nvmem_device_read(nvmem, offset, ETH_ALEN, mac_addr) == ETH_ALEN)
> - * pr_info("Read MAC addr from EEPROM: %pM\n", mac_addr);
> - * }
> - *
> - * This function pointer and context can now be set up in at24_platform_data.
> - */
> -
> -struct at24_platform_data {
> - u32 byte_len; /* size (sum of all addr) */
> - u16 page_size; /* for writes */
> - u8 flags;
> -#define AT24_FLAG_ADDR16 BIT(7) /* address pointer is 16 bit */
> -#define AT24_FLAG_READONLY BIT(6) /* sysfs-entry will be read-only */
> -#define AT24_FLAG_IRUGO BIT(5) /* sysfs-entry will be world-readable */
> -#define AT24_FLAG_TAKE8ADDR BIT(4) /* take always 8 addresses (24c00) */
> -#define AT24_FLAG_SERIAL BIT(3) /* factory-programmed serial number */
> -#define AT24_FLAG_MAC BIT(2) /* factory-programmed mac address */
> -#define AT24_FLAG_NO_RDROL BIT(1) /* does not auto-rollover reads to */
> - /* the next slave address */
> -
> - void (*setup)(struct nvmem_device *nvmem, void *context);
> - void *context;
> -};
> -
> -#endif /* _LINUX_AT24_H */
> --
> 2.18.0
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 6/7] net: mvneta: Don't use GRO on Armada 3720
From: Dave Taht @ 2018-08-08 17:57 UTC (permalink / raw)
To: Andrew Lunn
Cc: marek.behun, linux-arm-kernel, Linux Kernel Network Developers,
gregory.clement, tomas.hlavacek, linux
In-Reply-To: <20180808165846.GK7275@lunn.ch>
On Wed, Aug 8, 2018 at 10:00 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Wed, Aug 08, 2018 at 05:27:05PM +0200, Marek Behún wrote:
> > For some reason on Armada 3720 boards (EspressoBin and Turris Mox) the
> > networking driver behaves weirdly when using napi_gro_receive.
> >
> > For example downloading a big file from a local network (low ping) is
> > fast, but when downloading from a remote server (higher ping), the
> > download speed is at first high but drops rapidly to almost nothing or
> > absolutely nothing.
> >
> > This is fixed when using netif_receive_skb instead of napi_gro_receive.
>
> Before doing this, we should really understand what is going on. It is
> probably just a driver bug which needs fixing. And GRO should be good
> for performance, so we do want to use it, if possible.
I'd just disable it and worry about it later. The software gro in the
mvneta would batch up 64k and is one of the reasons why sch_cake does
gso splitting by default. (64k unsplit, downshifted to 1mbit = ~540ms
of latency). If this mvneta facility is in addition buggy, that
explains some puzzling things I've seen in various benchmarks. thx for
the steer as to what to look for!
IMHO: in general gro looks good on dumb single stream benchmarks, not
as useful on mixed routed traffic with more entropy, and batching
clutters up the mvneta receive path that otherwise could be draining
the rx ring and spitting packets into the rest of the system faster.
The mvneta is mostly (?) used on routing devices.
>
> Andrew
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
^ permalink raw reply
* [PATCH] fix build for MediaTek MT7610U USB wireless dongle
From: valdis.kletnieks @ 2018-08-08 20:16 UTC (permalink / raw)
To: Kalle Valo, David S. Miller; +Cc: netdev, linux-kernel, linux-wireless
The mt76x0 driver requires the mt76 core driver to actually function.
So add a 'select' to avoid embarrassing 'symbol unknown' errors
when attempting to modprobe it in a module tree that doesn't
include mt76.ko
Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
---
Still need to figure out why it totally fails to see the 5gz band,
it works find on 2.4 but ends up locked at 72mbits/sec. Works
OK otherwise...
diff --git a/drivers/net/wireless/mediatek/mt76/Kconfig b/drivers/net/wireless/mediatek/mt76/Kconfig
index 850611ad347a..b6c5f17dca30 100644
--- a/drivers/net/wireless/mediatek/mt76/Kconfig
+++ b/drivers/net/wireless/mediatek/mt76/Kconfig
@@ -11,6 +11,7 @@ config MT76x2_COMMON
config MT76x0U
tristate "MediaTek MT76x0U (USB) support"
+ select MT76_CORE
depends on MAC80211
depends on USB
help
^ permalink raw reply related
* Re: [PATCH v6 8/9] net/mlx5: Do not call pcie_print_link_status()
From: Leon Romanovsky @ 2018-08-08 17:27 UTC (permalink / raw)
To: Alex G.
Cc: Tal Gilboa, linux-pci, bhelgaas, jakub.kicinski, keith.busch,
alex_gagniuc, austin_bolen, shyam_iyer, Ariel Elior,
everest-linux-l2, David S. Miller, Michael Chan, Ganesh Goudar,
Jeff Kirsher, Tariq Toukan, Saeed Mahameed, Dirk van der Merwe,
netdev, linux-kernel, intel-wired-lan, linux-rdma, oss-drivers
In-Reply-To: <79264a38-e3e4-d270-95df-a09047f7a15e@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2996 bytes --]
On Wed, Aug 08, 2018 at 11:33:51AM -0500, Alex G. wrote:
>
>
> On 08/08/2018 10:56 AM, Tal Gilboa wrote:
> > On 8/8/2018 6:41 PM, Leon Romanovsky wrote:
> > > On Wed, Aug 08, 2018 at 05:23:12PM +0300, Tal Gilboa wrote:
> > > > On 8/8/2018 9:08 AM, Leon Romanovsky wrote:
> > > > > On Mon, Aug 06, 2018 at 06:25:42PM -0500, Alexandru Gagniuc wrote:
> > > > > > This is now done by the PCI core to warn of sub-optimal bandwidth.
> > > > > >
> > > > > > Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> > > > > > ---
> > > > > > drivers/net/ethernet/mellanox/mlx5/core/main.c | 4 ----
> > > > > > 1 file changed, 4 deletions(-)
> > > > > >
> > > > >
> > > > > Thanks,
> > > > > Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
> > > > >
> > > >
> > > > Alex,
> > > > I loaded mlx5 driver with and without these series. The report
> > > > in dmesg is
> > > > now missing. From what I understood, the status should be
> > > > reported at least
> > > > once, even if everything is in order.
> > >
> > > It is not what this series is doing and it removes prints completely if
> > > fabric can deliver more than card is capable.
> > >
> > > > We need this functionality to stay.
> > >
> > > I'm not sure that you need this information in driver's dmesg output,
> > > but most probably something globally visible and accessible per-pci
> > > device.
> >
> > Currently we have users that look for it. If we remove the dmesg print
> > we need this to be reported elsewhere. Adding it to sysfs for example
> > should be a valid solution for our case.
>
> I think a stop-gap measure is to leave the pcie_print_link_status() call in
> drivers that really need it for whatever reason. Implementing a reliable
> reporting through sysfs might take some tinkering, and I don't think it's a
> sufficient reason to block the heart of this series -- being able to detect
> bottlenecks and link downtraining.
IMHO, you did right change and it is better to replace this print to some
more generic solution now while you are doing it and don't leave leftovers.
Thanks
>
> Alex
>
> > >
> > > >
> > > > net-next (dmesg output for 07:00.0):
> > > > [270498.625351] mlx5_core 0000:07:00.0: firmware version: 14.22.4020
> > > > [270498.632130] mlx5_core 0000:07:00.0: 63.008 Gb/s available
> > > > PCIe bandwidth
> > > > (8 GT/s x8 link)
> > > > [270499.169533] (0000:07:00.0): E-Switch: Total vports 9, per vport: max
> > > > uc(1024) max mc(16384)
> > > > [270499.182358] mlx5_core 0000:07:00.0: Port module event:
> > > > module 0, Cable
> > > > plugged
> > > >
> > > > net-next + patches (dmesg output for 07:00.0):
> > > > [ 331.608472] mlx5_core 0000:07:00.0: firmware version: 14.22.4020
> > > > [ 332.564938] (0000:07:00.0): E-Switch: Total vports 9, per vport: max
> > > > uc(1024) max mc(16384)
> > > > [ 332.616271] mlx5_core 0000:07:00.0: Port module event: module
> > > > 0, Cable
> > > > plugged
> > > >
> > > >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH bpf 3/3] bpf, sockmap: fix cork timeout for select due to epipe
From: Daniel Borkmann @ 2018-08-08 17:23 UTC (permalink / raw)
To: netdev; +Cc: ast, john.fastabend, Daniel Borkmann
In-Reply-To: <20180808172315.4710-1-daniel@iogearbox.net>
I ran into the same issue as a009f1f396d0 ("selftests/bpf:
test_sockmap, timing improvements") where I had a broken
pipe error on the socket due to remote end timing out on
select and then shutting down it's sockets while the other
side was still sending. We may need to do a bigger rework
in general on the test_sockmap.c, but for now increase it
to a more suitable timeout.
Fixes: a18fda1a62c3 ("bpf: reduce runtime of test_sockmap tests")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: John Fastabend <john.fastabend@gmail.com>
---
tools/testing/selftests/bpf/test_sockmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/test_sockmap.c b/tools/testing/selftests/bpf/test_sockmap.c
index 9e78df2..0c7d9e5 100644
--- a/tools/testing/selftests/bpf/test_sockmap.c
+++ b/tools/testing/selftests/bpf/test_sockmap.c
@@ -354,7 +354,7 @@ static int msg_loop(int fd, int iov_count, int iov_length, int cnt,
while (s->bytes_recvd < total_bytes) {
if (txmsg_cork) {
timeout.tv_sec = 0;
- timeout.tv_usec = 1000;
+ timeout.tv_usec = 300000;
} else {
timeout.tv_sec = 1;
timeout.tv_usec = 0;
--
2.9.5
^ permalink raw reply related
* [PATCH bpf 1/3] bpf, sockmap: fix bpf_tcp_sendmsg sock error handling
From: Daniel Borkmann @ 2018-08-08 17:23 UTC (permalink / raw)
To: netdev; +Cc: ast, john.fastabend, Daniel Borkmann
In-Reply-To: <20180808172315.4710-1-daniel@iogearbox.net>
While working on bpf_tcp_sendmsg() code, I noticed that when a
sk->sk_err is set we error out with err = sk->sk_err. However
this is problematic since sk->sk_err is a positive error value
and therefore we will neither go into sk_stream_error() nor will
we report an error back to user space. I had this case with EPIPE
and user space was thinking sendmsg() succeeded since EPIPE is
a positive value, thinking we submitted 32 bytes. Fix it by
negating the sk->sk_err value.
Fixes: 4f738adba30a ("bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: John Fastabend <john.fastabend@gmail.com>
---
kernel/bpf/sockmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index 98fb793..f7360c4 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -1053,7 +1053,7 @@ static int bpf_tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
int copy;
if (sk->sk_err) {
- err = sk->sk_err;
+ err = -sk->sk_err;
goto out_err;
}
--
2.9.5
^ permalink raw reply related
* [PATCH bpf 2/3] bpf, sockmap: fix leak in bpf_tcp_sendmsg wait for mem path
From: Daniel Borkmann @ 2018-08-08 17:23 UTC (permalink / raw)
To: netdev; +Cc: ast, john.fastabend, Daniel Borkmann
In-Reply-To: <20180808172315.4710-1-daniel@iogearbox.net>
In bpf_tcp_sendmsg() the sk_alloc_sg() may fail. In the case of
ENOMEM, it may also mean that we've partially filled the scatterlist
entries with pages. Later jumping to sk_stream_wait_memory()
we could further fail with an error for several reasons, however
we miss to call free_start_sg() if the local sk_msg_buff was used.
Fixes: 4f738adba30a ("bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: John Fastabend <john.fastabend@gmail.com>
---
kernel/bpf/sockmap.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index f7360c4..c4d75c5 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -1048,7 +1048,7 @@ static int bpf_tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
timeo = sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT);
while (msg_data_left(msg)) {
- struct sk_msg_buff *m;
+ struct sk_msg_buff *m = NULL;
bool enospc = false;
int copy;
@@ -1116,8 +1116,11 @@ static int bpf_tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
wait_for_memory:
err = sk_stream_wait_memory(sk, &timeo);
- if (err)
+ if (err) {
+ if (m && m != psock->cork)
+ free_start_sg(sk, m);
goto out_err;
+ }
}
out_err:
if (err < 0)
--
2.9.5
^ permalink raw reply related
* [PATCH bpf 0/3] Couple of sockmap fixes
From: Daniel Borkmann @ 2018-08-08 17:23 UTC (permalink / raw)
To: netdev; +Cc: ast, john.fastabend, Daniel Borkmann
Two sockmap fixes in bpf_tcp_sendmsg(), and one fix for the
sockmap kernel selftest. Thanks!
Daniel Borkmann (3):
bpf, sockmap: fix bpf_tcp_sendmsg sock error handling
bpf, sockmap: fix leak in bpf_tcp_sendmsg wait for mem path
bpf, sockmap: fix cork timeout for select due to epipe
kernel/bpf/sockmap.c | 9 ++++++---
tools/testing/selftests/bpf/test_sockmap.c | 2 +-
2 files changed, 7 insertions(+), 4 deletions(-)
--
2.9.5
^ permalink raw reply
* Re: [PATCH net-next v1 1/1] net/tls: Combined memory allocation for decryption request
From: Dave Watson @ 2018-08-08 17:07 UTC (permalink / raw)
To: Vakul Garg; +Cc: netdev, borisp, aviadye, davem
In-Reply-To: <20180808130630.13568-2-vakul.garg@nxp.com>
On 08/08/18 06:36 PM, Vakul Garg wrote:
> For preparing decryption request, several memory chunks are required
> (aead_req, sgin, sgout, iv, aad). For submitting the decrypt request to
> an accelerator, it is required that the buffers which are read by the
> accelerator must be dma-able and not come from stack. The buffers for
> aad and iv can be separately kmalloced each, but it is inefficient.
> This patch does a combined allocation for preparing decryption request
> and then segments into aead_req || sgin || sgout || iv || aad.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
> ---
> + n_sgout = sg_nents(out_sg);
> +
> + n_sgin = skb_nsg(skb, rxm->offset + tls_ctx->rx.prepend_size,
> + rxm->full_len - tls_ctx->rx.prepend_size);
> + } else {
> +no_zerocopy:
label is unused now
^ permalink raw reply
* Re: [PATCH net-next] netfilter: nfnetlink_osf: fix using plain integer as NULL warning
From: Pablo Neira Ayuso @ 2018-08-08 17:05 UTC (permalink / raw)
To: Wei Yongjun
Cc: Jozsef Kadlecsik, Florian Westphal, netfilter-devel, coreteam,
netdev, kernel-janitors
In-Reply-To: <1533698624-107304-1-git-send-email-weiyongjun1@huawei.com>
On Wed, Aug 08, 2018 at 03:23:44AM +0000, Wei Yongjun wrote:
> Fixes the following sparse warning:
>
> net/netfilter/nfnetlink_osf.c:274:24: warning:
> Using plain integer as NULL pointer
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v1 6/7] net: mvneta: Don't use GRO on Armada 3720
From: Andrew Lunn @ 2018-08-08 16:58 UTC (permalink / raw)
To: Marek Behún
Cc: linux-arm-kernel, netdev, Gregory CLEMENT, Tomas Hlavacek,
Russell King - ARM Linux
In-Reply-To: <20180808152706.21727-7-marek.behun@nic.cz>
On Wed, Aug 08, 2018 at 05:27:05PM +0200, Marek Behún wrote:
> For some reason on Armada 3720 boards (EspressoBin and Turris Mox) the
> networking driver behaves weirdly when using napi_gro_receive.
>
> For example downloading a big file from a local network (low ping) is
> fast, but when downloading from a remote server (higher ping), the
> download speed is at first high but drops rapidly to almost nothing or
> absolutely nothing.
>
> This is fixed when using netif_receive_skb instead of napi_gro_receive.
Before doing this, we should really understand what is going on. It is
probably just a driver bug which needs fixing. And GRO should be good
for performance, so we do want to use it, if possible.
Andrew
^ permalink raw reply
* Re: [PATCH 03/28] nvmem: add a notifier chain
From: Bartosz Golaszewski @ 2018-08-08 16:30 UTC (permalink / raw)
To: Andrew Lunn
Cc: Bartosz Golaszewski, Jonathan Corbet, Sekhar Nori, Kevin Hilman,
Russell King, Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner
In-Reply-To: <20180808161353.GF7275@lunn.ch>
2018-08-08 18:13 GMT+02:00 Andrew Lunn <andrew@lunn.ch>:
> On Wed, Aug 08, 2018 at 05:31:25PM +0200, Bartosz Golaszewski wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> Add a blocking notifier chain with two events (add and remove) so that
>> users can get notified about the addition of nvmem devices they're
>> waiting for.
>>
>> We'll use this instead of the at24 setup callback in the mityomapl138
>> board file.
>
> Hi Bartosz
>
> What context is this notifier chain called in?
>
> I did something similar using the i2c notifier to try to work around
> the impending disappearing of the setup callback. But i got lockdep
> splats, because the notifier was called while some locks were being
> held, so it was not possible to register other i2c devices.
>
> The at24 setup callback is done as part of probe, so no important
> locks are held. Are any locks held when this notifier chain is called?
>
> Thanks
> Andrew
In the case of at24 it would be called from at24_probe() ->
nvmem_register() in process context. Would you mind testing it? Would
be great to see if it works on multiple setups.
Bart
^ permalink raw reply
* Re: [PATCH 00/33] net: ethernet: Mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2018-08-08 16:26 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-kernel, linux-net-drivers, ecree, bkenward, jes,
linux-acenic, michael.chan, nicolas.ferre, derek.chickles,
satananda.burla, felix.manlunas, raghu.vatsavayi, ganeshgr,
santosh, sgoutham, rric, linux-arm-kernel, linux-parisc,
sathya.perla, ajit.khaparde, sriharsha.basavapatna, somnath.kotur,
yisen.zhuang, salil.mehta, jeffrey.t.kirsher, intel-wired-lan,
tariqt, l
In-Reply-To: <20180807.175931.200772329178253653.davem@davemloft.net>
On 8/7/18 7:59 PM, David Miller wrote:
> From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
> Date: Tue, 7 Aug 2018 18:09:00 -0500
>
>> In preparation to enabling -Wimplicit-fallthrough, this patchset aims
>> to add some annotations in order to mark switch cases where we are
>> expecting to fall through.
>
> Ok, I went through all of these and they look good.
>
> If any are not correct we can revert/fix.
>
Yep. If anything is reported, I'll take a look right away.
> Series applied, thanks.
>
Thanks
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox