* [PATCHv2 1/3] dt-bindings: net: Add DT bindings for Socionext Netsec
From: jassisinghbrar @ 2017-12-12 17:15 UTC (permalink / raw)
To: netdev, devicetree
Cc: davem, arnd.bergmann, ard.biesheuvel, robh+dt, mark.rutland,
Jassi Brar, Jassi Brar
In-Reply-To: <1513098873-20977-1-git-send-email-jassisinghbrar@gmail.com>
From: Jassi Brar <jassisinghbrar@gmail.com>
This patch adds documentation for Device-Tree bindings for the
Socionext NetSec Controller driver.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
---
.../devicetree/bindings/net/socionext-netsec.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/socionext-netsec.txt
diff --git a/Documentation/devicetree/bindings/net/socionext-netsec.txt b/Documentation/devicetree/bindings/net/socionext-netsec.txt
new file mode 100644
index 0000000..4695969
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/socionext-netsec.txt
@@ -0,0 +1,45 @@
+* Socionext NetSec Ethernet Controller IP
+
+Required properties:
+- compatible: Should be "socionext,synquacer-netsec"
+- reg: Address and length of the control register area, followed by the
+ address and length of the EEPROM holding the MAC address and
+ microengine firmware
+- interrupts: Should contain ethernet controller interrupt
+- clocks: phandle to the PHY reference clock, and any other clocks to be
+ switched by runtime_pm
+- clock-names: Required only if more than a single clock is listed in 'clocks'.
+ The PHY reference clock must be named 'phy_refclk'
+- phy-mode: See ethernet.txt file in the same directory
+- phy-handle: phandle to select child phy
+
+Optional properties: (See ethernet.txt file in the same directory)
+- dma-coherent: Boolean property, must only be present if memory
+ accesses performed by the device are cache coherent
+- local-mac-address
+- mac-address
+- max-speed
+- max-frame-size
+
+Required properties for the child phy:
+- reg: phy address
+
+Example:
+ eth0: netsec@522D0000 {
+ compatible = "socionext,synquacer-netsec";
+ reg = <0 0x522D0000 0x0 0x10000>, <0 0x10000000 0x0 0x10000>;
+ interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_netsec>;
+ phy-mode = "rgmii";
+ max-speed = <1000>;
+ max-frame-size = <9000>;
+ phy-handle = <ðphy0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+ };
--
2.7.4
^ permalink raw reply related
* [PATCHv2 0/3] Socionext Synquacer NETSEC driver
From: jassisinghbrar @ 2017-12-12 17:14 UTC (permalink / raw)
To: netdev, devicetree
Cc: davem, arnd.bergmann, ard.biesheuvel, robh+dt, mark.rutland,
Jassi Brar
From: Jassi Brar <jaswinder.singh@linaro.org>
Hi,
Changes since v1
# Switched from using memremap to ioremap
# Implemented ndo_do_ioctl callback
# Defined optional 'dma-coherent' DT property
Jassi Brar (3):
dt-bindings: net: Add DT bindings for Socionext Netsec
net: socionext: Add Synquacer NetSec driver
MAINTAINERS: Add entry for Socionext ethernet driver
.../devicetree/bindings/net/socionext-netsec.txt | 43 +
MAINTAINERS | 7 +
drivers/net/ethernet/Kconfig | 1 +
drivers/net/ethernet/Makefile | 1 +
drivers/net/ethernet/socionext/Kconfig | 29 +
drivers/net/ethernet/socionext/Makefile | 1 +
drivers/net/ethernet/socionext/netsec.c | 1826 ++++++++++++++++++++
7 files changed, 1908 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/socionext-netsec.txt
create mode 100644 drivers/net/ethernet/socionext/Kconfig
create mode 100644 drivers/net/ethernet/socionext/Makefile
create mode 100644 drivers/net/ethernet/socionext/netsec.c
--
2.7.4
^ permalink raw reply
* Re: [PATCH net-next v5 1/2] net: add support for Cavium PTP coprocessor
From: Richard Cochran @ 2017-12-12 17:12 UTC (permalink / raw)
To: Aleksey Makarov
Cc: netdev, linux-arm-kernel, linux-kernel, Goutham, Sunil,
Radoslaw Biernacki, Robert Richter, David Daney,
Philippe Ombredanne
In-Reply-To: <d1e2faeb-ba5e-f324-efb5-da64e4b3ced3@cavium.com>
On Tue, Dec 12, 2017 at 12:41:35PM +0300, Aleksey Makarov wrote:
> If ptp_clock_register() returns NULL, the device is still paired with the driver,
> but the driver is not registered in the PTP core. When ethernet driver needs
> the reference to this cavium PTP driver, it calls cavium_ptp_get() that checks
> if ptp->ptp_clock is NULL and, if so, returns -ENODEV.
The pointer clock->ptp_clock can be NULL.
Yet you de-reference it here:
> +static void cavium_ptp_remove(struct pci_dev *pdev)
> +{
> + struct cavium_ptp *clock = pci_get_drvdata(pdev);
> + u64 clock_cfg;
> +
> + pci_set_drvdata(pdev, NULL);
> +
> + ptp_clock_unregister(clock->ptp_clock);
> +
> + clock_cfg = readq(clock->reg_base + PTP_CLOCK_CFG);
> + clock_cfg &= ~PTP_CLOCK_CFG_PTP_EN;
> + writeq(clock_cfg, clock->reg_base + PTP_CLOCK_CFG);
> +}
and here:
> +static inline int cavium_ptp_clock_index(struct cavium_ptp *clock)
> +{
> + return ptp_clock_index(clock->ptp_clock);
> +}
That needs to be fixed.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH v2 net-next] net: ethernet: ti: cpdma: correct error handling for chan create
From: Grygorii Strashko @ 2017-12-12 17:08 UTC (permalink / raw)
To: Ivan Khoronzhuk; +Cc: netdev, davem, linux-omap, linux-kernel
In-Reply-To: <1513096517-3905-1-git-send-email-ivan.khoronzhuk@linaro.org>
On 12/12/2017 10:35 AM, Ivan Khoronzhuk wrote:
> It's not correct to return NULL when that is actually an error and
> function returns errors in any other wrong case. In the same time,
> the cpsw driver and davinci emac doesn't check error case while
> creating channel and it can miss actual error. Also remove WARNs
> duplicated dev_err msgs.
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> ---
> drivers/net/ethernet/ti/cpsw.c | 12 +++++++++---
> drivers/net/ethernet/ti/davinci_cpdma.c | 2 +-
> drivers/net/ethernet/ti/davinci_emac.c | 9 +++++++--
> 3 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index a60a378..3c85a08 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -3065,10 +3065,16 @@ static int cpsw_probe(struct platform_device *pdev)
> }
>
> cpsw->txv[0].ch = cpdma_chan_create(cpsw->dma, 0, cpsw_tx_handler, 0);
> + if (IS_ERR(cpsw->txv[0].ch)) {
> + dev_err(priv->dev, "error initializing tx dma channel\n");
> + ret = PTR_ERR(cpsw->txv[0].ch);
> + goto clean_dma_ret;
> + }
> +
> cpsw->rxv[0].ch = cpdma_chan_create(cpsw->dma, 0, cpsw_rx_handler, 1);
> - if (WARN_ON(!cpsw->rxv[0].ch || !cpsw->txv[0].ch)) {
> - dev_err(priv->dev, "error initializing dma channels\n");
> - ret = -ENOMEM;
> + if (IS_ERR(cpsw->rxv[0].ch)) {
> + dev_err(priv->dev, "error initializing rx dma channel\n");
> + ret = PTR_ERR(cpsw->rxv[0].ch);
> goto clean_dma_ret;
> }
>
> diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
> index e4d6edf..6f9173f 100644
> --- a/drivers/net/ethernet/ti/davinci_cpdma.c
> +++ b/drivers/net/ethernet/ti/davinci_cpdma.c
> @@ -893,7 +893,7 @@ struct cpdma_chan *cpdma_chan_create(struct cpdma_ctlr *ctlr, int chan_num,
> chan_num = rx_type ? rx_chan_num(chan_num) : tx_chan_num(chan_num);
>
> if (__chan_linear(chan_num) >= ctlr->num_chan)
> - return NULL;
> + return ERR_PTR(-EINVAL);
>
> chan = devm_kzalloc(ctlr->dev, sizeof(*chan), GFP_KERNEL);
> if (!chan)
> diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
> index f58c0c6..3d4af64 100644
> --- a/drivers/net/ethernet/ti/davinci_emac.c
> +++ b/drivers/net/ethernet/ti/davinci_emac.c
> @@ -1870,10 +1870,15 @@ static int davinci_emac_probe(struct platform_device *pdev)
>
> priv->txchan = cpdma_chan_create(priv->dma, EMAC_DEF_TX_CH,
> emac_tx_handler, 0);
> + if (WARN_ON(IS_ERR(priv->txchan))) {
So, logically WARN_ON() should be removed in davinci_emac.c also. Right?
> + rc = PTR_ERR(priv->txchan);
> + goto no_cpdma_chan;
> + }
> +
> priv->rxchan = cpdma_chan_create(priv->dma, EMAC_DEF_RX_CH,
> emac_rx_handler, 1);
> - if (WARN_ON(!priv->txchan || !priv->rxchan)) {
> - rc = -ENOMEM;
> + if (WARN_ON(IS_ERR(priv->rxchan))) {
> + rc = PTR_ERR(priv->rxchan);
> goto no_cpdma_chan;
> }
>
>
--
regards,
-grygorii
^ permalink raw reply
* Re: [PATCH 2/4] sctp: Add ip option support
From: Marcelo Ricardo Leitner @ 2017-12-12 17:08 UTC (permalink / raw)
To: Richard Haines
Cc: selinux, netdev, linux-sctp, linux-security-module, paul,
vyasevich, nhorman, sds, eparis
In-Reply-To: <20171212160800.GE3532@localhost.localdomain>
On Tue, Dec 12, 2017 at 02:08:00PM -0200, Marcelo Ricardo Leitner wrote:
> Hi Richard,
>
> On Mon, Nov 27, 2017 at 07:31:21PM +0000, Richard Haines wrote:
> ...
> > --- a/net/sctp/socket.c
> > +++ b/net/sctp/socket.c
> > @@ -3123,8 +3123,10 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
> >
> > if (asoc) {
> > if (val == 0) {
> > + struct sctp_af *af = sp->pf->af;
> > val = asoc->pathmtu;
> > - val -= sp->pf->af->net_header_len;
> > + val -= af->ip_options_len(asoc->base.sk);
> > + val -= af->net_header_len;
> > val -= sizeof(struct sctphdr) +
> > sizeof(struct sctp_data_chunk);
> > }
>
> Right below here there is a call to sctp_frag_point(). That function
> also needs this tweak.
>
> Yes, we should simplify all these calculations. I have a patch to use
> sctp_frag_point on where it is currently recalculating it on
> sctp_datamsg_from_user(), but probably should include other places as
> well.
I have no further comments on this patchset other than the above and
LGTM.
Thanks Richard.
Marcelo
^ permalink raw reply
* Re: [PATCH net-next v4 1/2] bpf/tracing: allow user space to query prog array on the same tp
From: Alexei Starovoitov @ 2017-12-12 16:54 UTC (permalink / raw)
To: Peter Zijlstra, Yonghong Song; +Cc: daniel, netdev, kernel-team
In-Reply-To: <20171212090331.umlkvftrm3helfww@hirez.programming.kicks-ass.net>
On 12/12/17 1:03 AM, Peter Zijlstra wrote:
> On Mon, Dec 11, 2017 at 11:39:02AM -0800, Yonghong Song wrote:
>> The usage:
>> struct perf_event_query_bpf *query = malloc(...);
>> query.ids_len = ids_len;
>> err = ioctl(pmu_efd, PERF_EVENT_IOC_QUERY_BPF, &query);
>
> You didn't spot the fixes to your changelog ;-) The above should read
> something like:
>
> struct perf_event_query_bpf *query =
> malloc(sizeof(*query) + sizeof(u32) * ids_len);
> query->ids_len = ids_len;
> err = ioctl(pmu_efd, PERF_EVENT_IOC_QUERY_BPF, query);
sure. I fixed up this nit in commit log of patch 1 and in test_progs.c
of patch 2.
^ permalink raw reply
* [PATCH net-next] net: avoid skb_warn_bad_offload on IS_ERR
From: Willem de Bruijn @ 2017-12-12 16:39 UTC (permalink / raw)
To: netdev; +Cc: edumazet, davem, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
skb_warn_bad_offload warns when packets enter the GSO stack that
require skb_checksum_help or vice versa. Do not warn on arbitrary
bad packets. Packet sockets can craft many. Syzkaller was able to
demonstrate another one with eth_type games.
In particular, suppress the warning when segmentation returns an
error, which is for reasons other than checksum offload.
See also commit 36c92474498a ("net: WARN if skb_checksum_help() is
called on skb requiring segmentation") for context on this warning.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 8aa2f70995e8..b0eee49a2489 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2803,7 +2803,7 @@ struct sk_buff *__skb_gso_segment(struct sk_buff *skb,
segs = skb_mac_gso_segment(skb, features);
- if (unlikely(skb_needs_check(skb, tx_path)))
+ if (unlikely(skb_needs_check(skb, tx_path) && !IS_ERR(segs)))
skb_warn_bad_offload(skb);
return segs;
--
2.15.1.424.g9478a66081-goog
^ permalink raw reply related
* [PATCH v2 net-next] net: ethernet: ti: cpdma: correct error handling for chan create
From: Ivan Khoronzhuk @ 2017-12-12 16:35 UTC (permalink / raw)
To: grygorii.strashko
Cc: netdev, davem, linux-omap, linux-kernel, Ivan Khoronzhuk
It's not correct to return NULL when that is actually an error and
function returns errors in any other wrong case. In the same time,
the cpsw driver and davinci emac doesn't check error case while
creating channel and it can miss actual error. Also remove WARNs
duplicated dev_err msgs.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
drivers/net/ethernet/ti/cpsw.c | 12 +++++++++---
drivers/net/ethernet/ti/davinci_cpdma.c | 2 +-
drivers/net/ethernet/ti/davinci_emac.c | 9 +++++++--
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index a60a378..3c85a08 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -3065,10 +3065,16 @@ static int cpsw_probe(struct platform_device *pdev)
}
cpsw->txv[0].ch = cpdma_chan_create(cpsw->dma, 0, cpsw_tx_handler, 0);
+ if (IS_ERR(cpsw->txv[0].ch)) {
+ dev_err(priv->dev, "error initializing tx dma channel\n");
+ ret = PTR_ERR(cpsw->txv[0].ch);
+ goto clean_dma_ret;
+ }
+
cpsw->rxv[0].ch = cpdma_chan_create(cpsw->dma, 0, cpsw_rx_handler, 1);
- if (WARN_ON(!cpsw->rxv[0].ch || !cpsw->txv[0].ch)) {
- dev_err(priv->dev, "error initializing dma channels\n");
- ret = -ENOMEM;
+ if (IS_ERR(cpsw->rxv[0].ch)) {
+ dev_err(priv->dev, "error initializing rx dma channel\n");
+ ret = PTR_ERR(cpsw->rxv[0].ch);
goto clean_dma_ret;
}
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index e4d6edf..6f9173f 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -893,7 +893,7 @@ struct cpdma_chan *cpdma_chan_create(struct cpdma_ctlr *ctlr, int chan_num,
chan_num = rx_type ? rx_chan_num(chan_num) : tx_chan_num(chan_num);
if (__chan_linear(chan_num) >= ctlr->num_chan)
- return NULL;
+ return ERR_PTR(-EINVAL);
chan = devm_kzalloc(ctlr->dev, sizeof(*chan), GFP_KERNEL);
if (!chan)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index f58c0c6..3d4af64 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1870,10 +1870,15 @@ static int davinci_emac_probe(struct platform_device *pdev)
priv->txchan = cpdma_chan_create(priv->dma, EMAC_DEF_TX_CH,
emac_tx_handler, 0);
+ if (WARN_ON(IS_ERR(priv->txchan))) {
+ rc = PTR_ERR(priv->txchan);
+ goto no_cpdma_chan;
+ }
+
priv->rxchan = cpdma_chan_create(priv->dma, EMAC_DEF_RX_CH,
emac_rx_handler, 1);
- if (WARN_ON(!priv->txchan || !priv->rxchan)) {
- rc = -ENOMEM;
+ if (WARN_ON(IS_ERR(priv->rxchan))) {
+ rc = PTR_ERR(priv->rxchan);
goto no_cpdma_chan;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] tcp md5sig: Use skb's saddr when replying to an incoming segment
From: David Miller @ 2017-12-12 16:21 UTC (permalink / raw)
To: cpaasch; +Cc: netdev
In-Reply-To: <20171211080546.89418-1-cpaasch@apple.com>
From: Christoph Paasch <cpaasch@apple.com>
Date: Mon, 11 Dec 2017 00:05:46 -0800
> The MD5-key that belongs to a connection is identified by the peer's
> IP-address. When we are in tcp_v4(6)_reqsk_send_ack(), we are replying
> to an incoming segment from tcp_check_req() that failed the seq-number
> checks.
>
> Thus, to find the correct key, we need to use the skb's saddr and not
> the daddr.
>
> This bug seems to have been there since quite a while, but probably got
> unnoticed because the consequences are not catastrophic. We will call
> tcp_v4_reqsk_send_ack only to send a challenge-ACK back to the peer,
> thus the connection doesn't really fail.
>
> Fixes: 9501f9722922 ("tcp md5sig: Let the caller pass appropriate key for tcp_v{4,6}_do_calc_md5_hash().")
> Signed-off-by: Christoph Paasch <cpaasch@apple.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* [PATCH] openvswitch: Trim off padding before L3 conntrack processing
From: Ed Swierk @ 2017-12-12 16:17 UTC (permalink / raw)
To: ovs-dev, netdev, Pravin Shelar
Cc: Lance Richardson, Ed Swierk, Benjamin Warren, Keith Holleman
A short IPv4 packet may have up to 6 bytes of padding following the IP
payload when received on an Ethernet device.
In the normal IPv4 receive path, ip_rcv() trims the packet to
ip_hdr->tot_len before invoking NF_INET_PRE_ROUTING hooks (including
conntrack). Then any subsequent L3+ processing steps, like
nf_checksum(), use skb->len as the length of the packet, rather than
referring back to ip_hdr->tot_len. In the IPv6 receive path, ip6_rcv()
does the same using ipv6_hdr->payload_len.
In the OVS conntrack receive path, this trimming does not occur, so
the checksum verification in tcp_header() fails, printing "nf_ct_tcp:
bad TCP checksum". Extra zero bytes don't affect the checksum, but the
length in the IP pseudoheader does. That length is based on skb->len,
and without trimming, it doesn't match the length the sender used when
computing the checksum.
With this change, OVS conntrack trims IPv4 and IPv6 packets prior to
L3 processing.
Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
---
net/openvswitch/conntrack.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index d558e882ca0c..3a7c9215c431 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -1105,12 +1105,29 @@ int ovs_ct_execute(struct net *net, struct sk_buff *skb,
const struct ovs_conntrack_info *info)
{
int nh_ofs;
+ unsigned int nh_len;
int err;
/* The conntrack module expects to be working at L3. */
nh_ofs = skb_network_offset(skb);
skb_pull_rcsum(skb, nh_ofs);
+ /* Trim to L3 length since nf_checksum() doesn't expect padding. */
+ switch (skb->protocol) {
+ case htons(ETH_P_IP):
+ nh_len = ntohs(ip_hdr(skb)->tot_len);
+ break;
+ case htons(ETH_P_IPV6):
+ nh_len = ntohs(ipv6_hdr(skb)->payload_len)
+ + sizeof(struct ipv6hdr);
+ break;
+ default:
+ nh_len = skb->len;
+ }
+ err = pskb_trim_rcsum(skb, nh_len);
+ if (err)
+ return err;
+
if (key->ip.frag != OVS_FRAG_TYPE_NONE) {
err = handle_fragments(net, key, info->zone.id, skb);
if (err)
--
2.11.0
^ permalink raw reply related
* [PATCH] veth: Optionally pad packets to minimum Ethernet length
From: Ed Swierk @ 2017-12-12 16:13 UTC (permalink / raw)
To: netdev; +Cc: Ed Swierk, Benjamin Warren, Keith Holleman
Most physical Ethernet devices pad short packets to the minimum length
of 64 bytes (including FCS) on transmit. It can be useful to simulate
this behavior when debugging a problem that results from it (such as
incorrect L4 checksum calculation).
Padding is unnecessary for most applications so leave it off by
default. Enable padding only when the otherwise unused IFF_AUTOMEDIA
flag is set (e.g. by writing 0x5003 to flags in sysfs).
Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
---
drivers/net/veth.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index f5438d0978ca..292029bf4bb2 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -111,6 +111,12 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)
goto drop;
}
+ if (unlikely(dev->flags & IFF_AUTOMEDIA)) {
+ /* if eth_skb_pad returns an error the skb was freed */
+ if (eth_skb_pad(skb))
+ goto drop;
+ }
+
if (likely(dev_forward_skb(rcv, skb) == NET_RX_SUCCESS)) {
struct pcpu_vstats *stats = this_cpu_ptr(dev->vstats);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 2/4] sctp: Add ip option support
From: Marcelo Ricardo Leitner @ 2017-12-12 16:08 UTC (permalink / raw)
To: Richard Haines
Cc: selinux, netdev, linux-sctp, linux-security-module, paul,
vyasevich, nhorman, sds, eparis
In-Reply-To: <20171127193121.2666-1-richard_c_haines@btinternet.com>
Hi Richard,
On Mon, Nov 27, 2017 at 07:31:21PM +0000, Richard Haines wrote:
...
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -3123,8 +3123,10 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
>
> if (asoc) {
> if (val == 0) {
> + struct sctp_af *af = sp->pf->af;
> val = asoc->pathmtu;
> - val -= sp->pf->af->net_header_len;
> + val -= af->ip_options_len(asoc->base.sk);
> + val -= af->net_header_len;
> val -= sizeof(struct sctphdr) +
> sizeof(struct sctp_data_chunk);
> }
Right below here there is a call to sctp_frag_point(). That function
also needs this tweak.
Yes, we should simplify all these calculations. I have a patch to use
sctp_frag_point on where it is currently recalculating it on
sctp_datamsg_from_user(), but probably should include other places as
well.
Marcelo
^ permalink raw reply
* Re: [PATCH net-next v4 1/5] net: Introduce NETIF_F_GRO_HW.
From: Alexander Duyck @ 2017-12-12 15:57 UTC (permalink / raw)
To: Michael Chan
Cc: David Miller, Netdev, Andrew Gospodarek, Ariel Elior,
everest-linux-l2
In-Reply-To: <1512992470-28861-2-git-send-email-michael.chan@broadcom.com>
On Mon, Dec 11, 2017 at 3:41 AM, Michael Chan <michael.chan@broadcom.com> wrote:
> Introduce NETIF_F_GRO_HW feature flag for NICs that support hardware
> GRO. With this flag, we can now independently turn on or off hardware
> GRO when GRO is on. Previously, drivers were using NETIF_F_GRO to
> control hardware GRO and so it cannot be independently turned on or
> off without affecting GRO.
>
> Hardware GRO (just like GRO) guarantees that packets can be re-segmented
> by TSO/GSO to reconstruct the original packet stream. Logically,
> GRO_HW should depend on GRO since it a subset, but we will let
> individual drivers enforce this dependency as they see fit.
>
> Since NETIF_F_GRO is not propagated between upper and lower devices,
> NETIF_F_GRO_HW should follow suit since it is a subset of GRO. In other
> words, a lower device can independent have GRO/GRO_HW enabled or disabled
> and no feature propagation is required. This will preserve the current
> GRO behavior. This can be changed later if we decide to propagate GRO/
> GRO_HW/RXCSUM from upper to lower devices.
>
> Cc: Ariel Elior <Ariel.Elior@cavium.com>
> Cc: everest-linux-l2@cavium.com
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
> ---
> Documentation/networking/netdev-features.txt | 8 ++++++++
> include/linux/netdev_features.h | 3 +++
> net/core/dev.c | 10 ++++++++++
> net/core/ethtool.c | 1 +
> 4 files changed, 22 insertions(+)
>
> diff --git a/Documentation/networking/netdev-features.txt b/Documentation/networking/netdev-features.txt
> index 7413eb0..8f36527 100644
> --- a/Documentation/networking/netdev-features.txt
> +++ b/Documentation/networking/netdev-features.txt
> @@ -163,3 +163,11 @@ This requests that the NIC receive all possible frames, including errored
> frames (such as bad FCS, etc). This can be helpful when sniffing a link with
> bad packets on it. Some NICs may receive more packets if also put into normal
> PROMISC mode.
> +
> +* rx-gro-hw
> +
> +This requests that the NIC enables Hardware GRO (generic receive offload).
> +Hardware GRO is basically the exact reverse of TSO, and is generally
> +stricter than Hardware LRO. A packet stream merged by Hardware GRO must
> +be re-segmentable by GSO or TSO back to the exact original packet stream.
> +Hardware GRO is dependent on GRO and RXCSUM.
This last line should probably be updated since we made the change
that dropped the dependency on software GRO.
> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
> index b1b0ca7..db84c51 100644
> --- a/include/linux/netdev_features.h
> +++ b/include/linux/netdev_features.h
> @@ -78,6 +78,8 @@ enum {
> NETIF_F_HW_ESP_TX_CSUM_BIT, /* ESP with TX checksum offload */
> NETIF_F_RX_UDP_TUNNEL_PORT_BIT, /* Offload of RX port for UDP tunnels */
>
> + NETIF_F_GRO_HW_BIT, /* Hardware Generic receive offload */
> +
> /*
> * Add your fresh new feature above and remember to update
> * netdev_features_strings[] in net/core/ethtool.c and maybe
> @@ -97,6 +99,7 @@ enum {
> #define NETIF_F_FRAGLIST __NETIF_F(FRAGLIST)
> #define NETIF_F_FSO __NETIF_F(FSO)
> #define NETIF_F_GRO __NETIF_F(GRO)
> +#define NETIF_F_GRO_HW __NETIF_F(GRO_HW)
> #define NETIF_F_GSO __NETIF_F(GSO)
> #define NETIF_F_GSO_ROBUST __NETIF_F(GSO_ROBUST)
> #define NETIF_F_HIGHDMA __NETIF_F(HIGHDMA)
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 8aa2f70..bf0149e 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -7424,6 +7424,16 @@ static netdev_features_t netdev_fix_features(struct net_device *dev,
> features &= ~dev->gso_partial_features;
> }
>
> + if (!(features & NETIF_F_RXCSUM)) {
> + /* NETIF_F_GRO_HW implies doing RXCSUM. If the user does not
> + * want to enable RXCSUM, logically, we should disable GRO_HW.
> + */
It might be in our interest here to explain why. Specifically that
"The Rx checksum can no longer be verified once a packet is modified
as a result of GRO_HW, therefore we cannot allow GRO_HW to be enabled
when RXCSUM is disabled." or something to that effect. Otherwise there
isn't a good explanation as to why GRO_HW implies this.
> + if (features & NETIF_F_GRO_HW) {
> + netdev_dbg(dev, "Dropping NETIF_F_GRO_HW since no RXCSUM feature.\n");
> + features &= ~NETIF_F_GRO_HW;
> + }
> + }
> +
> return features;
> }
>
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index f8fcf45..50a7920 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -73,6 +73,7 @@ int ethtool_op_get_ts_info(struct net_device *dev, struct ethtool_ts_info *info)
> [NETIF_F_LLTX_BIT] = "tx-lockless",
> [NETIF_F_NETNS_LOCAL_BIT] = "netns-local",
> [NETIF_F_GRO_BIT] = "rx-gro",
> + [NETIF_F_GRO_HW_BIT] = "rx-gro-hw",
> [NETIF_F_LRO_BIT] = "rx-lro",
>
> [NETIF_F_TSO_BIT] = "tx-tcp-segmentation",
^ permalink raw reply
* AF_VSOCK connection refused errno
From: Stefan Hajnoczi @ 2017-12-12 15:53 UTC (permalink / raw)
To: Jorgen Hansen; +Cc: Dexuan Cui, netdev
[-- Attachment #1: Type: text/plain, Size: 559 bytes --]
When connect(2) fails because the peer is not listening the virtio vsock
transport returns ECONNRESET. I believe the VMCI transport does the
same (based on code inspection).
Jorgen: Can you confirm this VMCI transport behavior?
I'd like to change to ECONNREFUSED for all transports because developers
will be surprised when they get ECONNRESET. It makes porting AF_INET
code harder.
On the other hand, it may be too late to fix this if there userspace
applications that rely on ECONNRESET? I'm not aware of any such
applications myself.
Thanks,
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] libbpf: add function to setup XDP
From: David Miller @ 2017-12-12 15:53 UTC (permalink / raw)
To: makita.toshiaki; +Cc: eric, netdev, linux-kernel, ast, daniel
In-Reply-To: <c1be066a-eb39-c9e0-b21b-4bb4da280b26@lab.ntt.co.jp>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Date: Mon, 11 Dec 2017 11:24:12 +0900
> On 2017/12/09 23:43, Eric Leblond wrote:
>> Most of the code is taken from set_link_xdp_fd() in bpf_load.c and
>> slightly modified to be library compliant.
>>
>> Signed-off-by: Eric Leblond <eric@regit.org>
> ...
>> +int bpf_set_link_xdp_fd(int ifindex, int fd, __u32 flags)
> ...
>> + for (nh = (struct nlmsghdr *)buf; NLMSG_OK(nh, len);
>> + nh = NLMSG_NEXT(nh, len)) {
>> + if (nh->nlmsg_pid != getpid()) {
>
> Generally nlmsg_pid should not be compared with process id.
> See man netlink and
> https://github.com/iovisor/bcc/pull/1275/commits/69ce96a54c55960c8de3392061254c97b6306a6d
Right. I wish we had never named this "pid", it gets misinterpreted
way too easily.
^ permalink raw reply
* gso_type field for LRO packets
From: Gal Pressman @ 2017-12-12 15:53 UTC (permalink / raw)
To: netdev@vger.kernel.org, Eric Dumazet, David S. Miller,
Ben Hutchings, Michael S. Tsirkin
Cc: Tariq Toukan, Saeed Mahameed
Hi all,
I've been exploring hardware LRO related code in the stack and came across an inconsistency I don't quite understand.
When receiving a hardware LRO packet, most of the drivers set skb_shinfo(skb)->gso_type (For example [1]) in order to prevent macvtap from breaking.
According to include/linux/skbuff.h +/skb_warn_if_lro, LRO should set gso_size but not gso_type, which contradicts the drivers implementation and makes the check redundant.
Can anyone advise what is the correct driver implementation? should we change skb_warn_if_lro() implementation?
Regards,
Gal
[1] commit bd69ba798e21 ("qlcnic: set gso_type")
^ permalink raw reply
* Re: [PATCH net-next 0/3] tcp: better receiver autotuning
From: David Miller @ 2017-12-12 15:53 UTC (permalink / raw)
To: edumazet; +Cc: ncardwell, ycheng, soheil, weiwan, priyarjha, netdev,
eric.dumazet
In-Reply-To: <20171211015504.26551-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Sun, 10 Dec 2017 17:55:01 -0800
> Now TCP senders no longer backoff when a drop is detected,
> it appears we are very often receive window limited.
>
> This series makes tcp_rcv_space_adjust() slightly more robust
> and responsive.
Series applied, thanks.
^ permalink raw reply
* [PATCH iproute2] tc: bash-completion: add missing 'classid' keyword
From: Davide Caratti @ 2017-12-12 15:45 UTC (permalink / raw)
To: Stephen Hemminger, netdev; +Cc: Yotam Gigi
users of 'matchall' filter can specify a value for the class id: update
bash-completion accordingly.
Fixes: b32c0b64fa2b ("tc: bash-completion: Add support for matchall")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
bash-completion/tc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bash-completion/tc b/bash-completion/tc
index 80d12972..29bca5d9 100644
--- a/bash-completion/tc
+++ b/bash-completion/tc
@@ -450,7 +450,7 @@ _tc_filter_options()
return 0
;;
matchall)
- _tc_once_attr 'action skip_sw skip_hw'
+ _tc_once_attr 'action classid skip_sw skip_hw'
return 0
;;
flower)
--
2.13.6
^ permalink raw reply related
* Re: [RFC PATCH 0/9] ethtool netlink interface (WiP)
From: Roopa Prabhu @ 2017-12-12 15:32 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev, linux-kernel
In-Reply-To: <cover.1513000306.git.mkubecek@suse.cz>
On Mon, Dec 11, 2017 at 5:53 AM, Michal Kubecek <mkubecek@suse.cz> wrote:
> This is still work in progress and only a very small part of the ioctl
> interface is reimplemented but I would like to get some comments before
> the patchset becomes too big and changing things becomes too tedious.
>
> The interface used for communication between ethtool and kernel is based on
> ioctl() and suffers from many problems. The most pressing seems the be the
> lack of extensibility. While some of the newer commands use structures
> designed to allow future extensions (e.g. GFEATURES or TEST), most either
> allow no extension at all (GPAUSEPARAM, GCOALESCE) or only limited set of
> reserved fields (GDRVINFO, GEEE). Even most of those which support future
> extensions limit the data types that can be used.
>
> This series aims to provide an alternative interface based on netlink which
> is what other network configuration utilities use. In particular, it uses
> generic netlink (family "ethtool"). The goal is to provide an interface
> which would be extensible, flexible and practical both for ethtool and for
> other network configuration tools (e.g. wicked or systemd-networkd).
>
> The interface is documented in Documentation/networking/ethtool-netlink.txt
>
> I'll post RFC patch series for ethtool in a few days, it still needs some
> more polishing.
>
> Basic concepts:
>
> - the interface is based on generic netlink (family name "ethtool")
>
> - provide everything ioctl can do but allow easier future extensions
>
> - inextensibility of ioctl interface resulted in way too many commands,
> many of them obsoleted by newer ones; reduce the number by ignoring the
> obsolete commands and grouping some together
>
> - for "set" type commands, netlink allows providing only the attributes to
> be changed; therefore we don't need a get-modify-set cycle, userspace can
> simply say what it wants to change and how
>
> - be less dependent on ethtool and kernel being in sync; allow e.g. saying
> "ethtool -s eth0 advertise xyz off" without knowing what "xyz" means;
> it's kernel's job to know what mode "xyz" is and if it exists and is
> supported
>
> Unresolved questions/tasks:
>
> - allow dumps for "get" type requests, e.g. listing EEE settings for all
> interfaces in current netns
>
> - find reasonable format for data transfers (e.g. eeprom dump or flash)
>
> - while the netlink interface allows easy future extensions, ethtool_ops
> interface does not; some settings could be implemented using tunables and
> accessed via relevant netlink messages (as well as tunables) from
> userspace but in the long term, something better will be needed
>
> - it would be nice if driver could provide useful error/warning messages to
> be passed to userspace via extended ACK; example: while testing, I found
> a driver which only allows values 0, 1, 3 and 10000 for certain parameter
> but the only way poor user can find out is either by trying all values or
> by checking driver source
>
> Michal Kubecek (9):
> netlink: introduce nla_put_bitfield32()
> ethtool: introduce ethtool netlink interface
> ethtool: helper functions for netlink interface
> ethtool: netlink bitset handling
> ethtool: implement GET_DRVINFO message
> ethtool: implement GET_SETTINGS message
> ethtool: implement SET_SETTINGS message
> ethtool: implement GET_PARAMS message
> ethtool: implement SET_PARAMS message
>
Thanks for working on this!. Agree with most comments already
discussed on this thread.
I would prefer if we fold ethtool netlink into devlink since there is
already an overlap.
many reasons:
- have just one driver api for device global and per port config
(devlink already provides that)
- some of the devlink commands like port split/unsplit can already be
applied per netdev (and since you bring up network interface managers,
we are looking at getting these in network managers for switch ports)
- if we keep them separate, we will soon see that drivers will need
handlers for both devlink and ethtool
- and the overlap is going to be confusing for both drivers and
user-space
^ permalink raw reply
* Re: [PATCH net-next] net: phy: marvell10g: remove XGMII as an option for 88x3310
From: Andrew Lunn @ 2017-12-12 14:59 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1eOk3i-00010j-0V@rmk-PC.armlinux.org.uk>
On Tue, Dec 12, 2017 at 12:53:18PM +0000, Russell King wrote:
> Remove XGMII as an option for the 88x3310 PHY driver, as the PHY doesn't
> support XGMII's 32-bit data lanes. It supports USXGMII, which is not
> XGMII, but a single-lane serdes interface - see
> https://developer.cisco.com/site/usgmii-usxgmii/
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next] tcp: Remove tcp_low_latency sysctl.
From: David Miller @ 2017-12-12 14:49 UTC (permalink / raw)
To: xiangxia.m.yue; +Cc: fw, netdev
In-Reply-To: <1513089788-2626-1-git-send-email-xiangxia.m.yue@gmail.com>
From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Date: Tue, 12 Dec 2017 06:43:08 -0800
> The prequeue has been removed from the kernel. If we leave
> the tcp_low_latency in kernel, it may confuse the users.
> If users can't find the option, the doc may tell them why.
> So we remove also the sysctl about tcp_low_latency.
>
> Signed-off-by: Tonghao Zhang <zhangtonghao@didichuxing.com>
If you remove the sysctl, it will break scripts.
That's why we left it around.
^ permalink raw reply
* [PATCH net-next] tcp: Remove tcp_low_latency sysctl.
From: Tonghao Zhang @ 2017-12-12 14:43 UTC (permalink / raw)
To: fw; +Cc: netdev, Tonghao Zhang
The prequeue has been removed from the kernel. If we leave
the tcp_low_latency in kernel, it may confuse the users.
If users can't find the option, the doc may tell them why.
So we remove also the sysctl about tcp_low_latency.
Signed-off-by: Tonghao Zhang <zhangtonghao@didichuxing.com>
---
Documentation/networking/ip-sysctl.txt | 2 +-
net/ipv4/sysctl_net_ipv4.c | 10 ----------
2 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 77f4de59dc9c..ac35f5b59739 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -356,7 +356,7 @@ tcp_l3mdev_accept - BOOLEAN
compiled with CONFIG_NET_L3_MASTER_DEV.
tcp_low_latency - BOOLEAN
- This is a legacy option, it has no effect anymore.
+ This is an obsolete option, it has been removed from kernel.
tcp_max_orphans - INTEGER
Maximal number of TCP sockets not attached to any user file handle,
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 4602af6d5358..dfebbfcccb87 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -45,9 +45,6 @@ static int tcp_syn_retries_max = MAX_TCP_SYNCNT;
static int ip_ping_group_range_min[] = { 0, 0 };
static int ip_ping_group_range_max[] = { GID_T_MAX, GID_T_MAX };
-/* obsolete */
-static int sysctl_tcp_low_latency __read_mostly;
-
/* Update system visible IP port range */
static void set_local_port_range(struct net *net, int range[2])
{
@@ -438,13 +435,6 @@ static struct ctl_table ipv4_table[] = {
.extra1 = &one,
},
{
- .procname = "tcp_low_latency",
- .data = &sysctl_tcp_low_latency,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec
- },
- {
.procname = "tcp_congestion_control",
.mode = 0644,
.maxlen = TCP_CA_NAME_MAX,
--
2.13.6
^ permalink raw reply related
* [PATCH net-next] net: sk_pacing_shift_update() helper
From: Eric Dumazet @ 2017-12-12 14:34 UTC (permalink / raw)
To: Felix Fietkau, David Miller
Cc: netdev, Johannes Berg, Toke Høiland-Jørgensen,
Kir Kolyshkin
In-Reply-To: <1511890429.16595.20.camel@gmail.com>
From: Eric Dumazet <edumazet@google.com>
In commit 3a9b76fd0db9 ("tcp: allow drivers to tweak TSQ logic")
I gave a code sample to set sk->sk_pacing_shift that was not complete.
Better add a helper that can be used by drivers without worries,
and maybe amended in the future.
A wifi driver might use it from its ndo_start_xmit()
Following call would setup TCP to allow up to ~8ms of queued data per
flow.
sk_pacing_shift_update(skb->sk, 7);
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/sock.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/net/sock.h b/include/net/sock.h
index 9155da42269208b358df8535b14dfd3dba509365..9a9047268d375496bccc954d03ec20baf4177fd3 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2407,4 +2407,15 @@ static inline int sk_get_rmem0(const struct sock *sk, const struct proto *proto)
return *proto->sysctl_rmem;
}
+/* Default TCP Small queue budget is ~1 ms of data (1sec >> 10)
+ * Some wifi drivers need to tweak it to get more chunks.
+ * They can use this helper from their ndo_start_xmit()
+ */
+static inline void sk_pacing_shift_update(struct sock *sk, int val)
+{
+ if (!sk || !sk_fullsock(sk) || sk->sk_pacing_shift == val)
+ return;
+ sk->sk_pacing_shift = val;
+}
+
#endif /* _SOCK_H */
^ permalink raw reply related
* Re: [PATCH][next] net: phy: meson-gxl: make function meson_gxl_read_status static
From: Jerome Brunet @ 2017-12-12 14:20 UTC (permalink / raw)
To: Colin King, Andrew Lunn, Florian Fainelli, Carlo Caione,
Kevin Hilman, netdev, linux-arm-kernel, linux-amlogic
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20171212130311.17185-1-colin.king@canonical.com>
On Tue, 2017-12-12 at 13:03 +0000, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The function meson_gxl_read_status is local to the source and does
> not need to be in global scope, so make it static.
>
> Cleans up sparse warning:
> symbol 'meson_gxl_read_status' was not declared. Should it be static?
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Indeed, silly mistake, thx for spotting it.
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
^ permalink raw reply
* Re: [REGRESSION][4.13.y][4.14.y][v4.15.y] net: reduce skb_warn_bad_offload() noise
From: David Miller @ 2017-12-12 14:10 UTC (permalink / raw)
To: willemdebruijn.kernel
Cc: gregkh, joseph.salisbury, edumazet, dvyukov, willemb, daniel,
jakub.kicinski, linux, john.fastabend, me, idosch, netdev,
linux-kernel, stable, 1715609
In-Reply-To: <CAF=yD-K5EmFr5z2xjmCZCqdprqQ5vmfxV3od9xBnxBQhY+_qgQ@mail.gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Mon, 11 Dec 2017 16:56:56 -0500
> On Mon, Dec 11, 2017 at 4:44 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>> On Mon, Dec 11, 2017 at 04:25:26PM -0500, Willem de Bruijn wrote:
>>> Note that UFO was removed in 4.14 and that skb_warn_bad_offload
>>> can happen for various types of packets, so there may be multiple
>>> independent bug reports. I'm investigating two other non-UFO reports
>>> just now.
>>
>> Meta-comment, now that UFO is gone from mainline, I'm wondering if I
>> should just delete it from 4.4 and 4.9 as well. Any objections for
>> that? I'd like to make it easy to maintain these kernels for a while,
>> and having them diverge like this, with all of the issues around UFO,
>> seems like it will just make life harder for myself if I leave it in.
>>
>> Any opinions?
>
> Some of that removal had to be reverted with commit 0c19f846d582
> ("net: accept UFO datagrams from tuntap and packet") for VM live
> migration between kernels.
>
> Any backports probably should squash that in at the least. Just today
> another thread discussed that that patch may not address all open
> issues still, so it may be premature to backport at this point.
> http://lkml.kernel.org/r/<d71df64e-e65f-4db4-6f2e-c002c15fcbe4@01019freenet.de>
I would probably discourage backporting the UFO removal, at least for
now.
^ 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