* Re: [pull request][for-next 0/6] Mellanox mlx5 updates 2017-05-23
From: David Miller @ 2017-05-25 16:02 UTC (permalink / raw)
To: saeedm-VPRAkNaXOzVWk0Htik3J/w
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, ilant-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <20170523114404.20387-1-saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
From: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Date: Tue, 23 May 2017 14:43:58 +0300
> Hi Dave and Doug,
>
> This series introduces some small updates and FPGA support to the mlx5
> core/ethernet and IB drivers.
>
> For more details please see below.
>
> Please pull and let me know if there's any problem.
Ok, I've pulled this into net-next.
Doug let me know if there are any merge hassles we need to coordinate on.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] bpf: update perf event helper function signature and documentation
From: David Miller @ 2017-05-25 16:07 UTC (permalink / raw)
To: qinteng; +Cc: peterz, bgregg, daniel, netdev, linux-kernel, Kernel-team, ast
In-Reply-To: <BB53B290-EED3-4B92-8D2D-33954D7B6C68@fb.com>
From: Teng Qin <qinteng@fb.com>
Date: Tue, 23 May 2017 03:17:31 +0000
> Alexei said it was due to Clang not taking u64, u32 etc. for compilation.
> I didn’t know the context and just used them. But apparently, something
> changed and now they build and run OK......
These types are %100 compiler agnostic. Clang doesn't care. All
compilers can understand:
typedef unsigned int u32;
So it's not a Clang specific issue.
The problem could only have to do with whether the types get typdef'd
or not with the header files that are used in conjunction with the
file we are talking about here.
And if we do get a proper set of defines from linux/types.h these days
we should:
1) Make that explicit, by including linux/types.h in bpf_helpers.h
2) Use those types universally in this file where we were avoiding
doing so
This header file also uses "SEC" and expects to get this definition
implicitly, and therefore there is another header file that
bpf_helpers.h must include in order to explicitly and reliably have
that definition.
Just changing one prototype, and relying on getting the types
indirectly by other header files including by whoever incudes
bpf_helpers.h is not the way to go.
Thanks.
^ permalink raw reply
* Re: [PATCH net] ip6_tunnel, ip6_gre: fix setting of DSCP on encapsulated packets
From: David Miller @ 2017-05-25 16:11 UTC (permalink / raw)
To: petedaws; +Cc: kuznet, jmorris, yoshfuji, kaber, stephen, netdev, linux-kernel
In-Reply-To: <20170523143616.38116e8f@gmail.com>
From: Peter Dawson <petedaws@gmail.com>
Date: Tue, 23 May 2017 14:36:16 +1000
> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=195661
This is not the correct way to use the Fixes: tag.
You should specify the commit that introduced the regression
between 4.9.x and 4.10.x, and that you are fixing here.
The correct format for the commit references is the 12 initial digits
of the SHA1_ID of the commit, followed by a space, followed by the
commit log message header line text enclosed in parentheses and
double quotes with no line breaks whatsoever.
Thank you.
^ permalink raw reply
* Re: [patch net-next] net: sched: cls_api: make reclassify return all the way back to the original tp
From: David Miller @ 2017-05-25 16:12 UTC (permalink / raw)
To: jiri
Cc: netdev, jhs, xiyou.wangcong, dsa, edumazet, daniel,
alexander.h.duyck, simon.horman, mlxsw
In-Reply-To: <20170523071159.1951-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 23 May 2017 09:11:59 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> With the introduction of chain goto action, the reclassification would
> cause the re-iteration of the actual chain. It makes more sense to restart
> the whole thing and re-iterate starting from the original tp - start
> of chain 0.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied, thanks Jiri.
^ permalink raw reply
* Re: [Patch net-next] net_sched: only create filter chains for new filters/actions
From: David Miller @ 2017-05-25 16:14 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, jhs, jiri
In-Reply-To: <1495557757-31371-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 23 May 2017 09:42:37 -0700
> tcf_chain_get() always creates a new filter chain if not found
> in existing ones. This is totally unnecessary when we get or
> delete filters, new chain should be only created for new filters
> (or new actions).
>
> Fixes: 5bc1701881e3 ("net: sched: introduce multichain support for filters")
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Indeed, get and delete requests should not create new objects, ever.
I have pretty much no idea why Jiri is making such a big fuss about
this change, to be quite honest. :-)
Applied, thanks Cong.
^ permalink raw reply
* [PATCH net-next v2 0/3] net: phy: Create sysfs reciprocal links for attached_dev/phydev
From: Florian Fainelli @ 2017-05-25 16:21 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, Florian Fainelli
Hi David, Andrew,
This patch series addresses a device topology shortcoming where a program
scanning /sys would not be able to establish a mapping between the network
device and the PHY device.
In the process it turned out that no PHY device documentation existed for
sysfs attributes.
Thanks!
Changes in v2:
- document possible phy_interface values in sysfs-class-net-phydev
Florian Fainelli (3):
net: phy: Create sysfs reciprocal links for attached_dev/phydev
net: sysfs: Document "phydev" symbolic link
net: sysfs: Document PHY device sysfs attributes
Documentation/ABI/testing/sysfs-class-net | 8 ++++++
Documentation/ABI/testing/sysfs-class-net-phydev | 36 ++++++++++++++++++++++++
drivers/net/phy/phy_device.c | 11 ++++++++
3 files changed, 55 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-net-phydev
--
2.9.3
^ permalink raw reply
* [PATCH net-next v2 1/3] net: phy: Create sysfs reciprocal links for attached_dev/phydev
From: Florian Fainelli @ 2017-05-25 16:21 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, Florian Fainelli
In-Reply-To: <20170525162143.18319-1-f.fainelli@gmail.com>
There is currently no way for a program scanning /sys to know whether a
network device is attached to a particular PHY device, just like the PHY
device is not pointed back to its attached network device.
Create a symbolic link in the network device's namespace named "phydev"
which points to the PHY device and create a symbolic link in the PHY
device's namespace named "attached_dev" that points back to the network
device. These links are set up during phy_attach_direct() and removed
during phy_detach() for symetry.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/phy_device.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 1219eeab69d1..8151477c7027 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -960,6 +960,15 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
phydev->attached_dev = dev;
dev->phydev = phydev;
+ err = sysfs_create_link(&phydev->mdio.dev.kobj, &dev->dev.kobj,
+ "attached_dev");
+ if (err)
+ goto error;
+
+ err = sysfs_create_link(&dev->dev.kobj, &phydev->mdio.dev.kobj,
+ "phydev");
+ if (err)
+ goto error;
phydev->dev_flags = flags;
@@ -1050,6 +1059,8 @@ void phy_detach(struct phy_device *phydev)
struct mii_bus *bus;
int i;
+ sysfs_remove_link(&dev->dev.kobj, "phydev");
+ sysfs_remove_link(&phydev->mdio.dev.kobj, "attached_dev");
phydev->attached_dev->phydev = NULL;
phydev->attached_dev = NULL;
phy_suspend(phydev);
--
2.9.3
^ permalink raw reply related
* [PATCH net-next v2 2/3] net: sysfs: Document "phydev" symbolic link
From: Florian Fainelli @ 2017-05-25 16:21 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, Florian Fainelli
In-Reply-To: <20170525162143.18319-1-f.fainelli@gmail.com>
Now that we link the network device to its PHY device, document this
sysfs symbolic link.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Documentation/ABI/testing/sysfs-class-net | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net
index 668604fc8e06..6856da99b6f7 100644
--- a/Documentation/ABI/testing/sysfs-class-net
+++ b/Documentation/ABI/testing/sysfs-class-net
@@ -251,3 +251,11 @@ Contact: netdev@vger.kernel.org
Description:
Indicates the unique physical switch identifier of a switch this
port belongs to, as a string.
+
+What: /sys/class/net/<iface>/phydev
+Date: May 2017
+KernelVersion: 4.13
+Contact: netdev@vger.kernel.org
+Description:
+ Symbolic link to the PHY device this network device is attached
+ to.
--
2.9.3
^ permalink raw reply related
* [PATCH net-next v2 3/3] net: sysfs: Document PHY device sysfs attributes
From: Florian Fainelli @ 2017-05-25 16:21 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, Florian Fainelli
In-Reply-To: <20170525162143.18319-1-f.fainelli@gmail.com>
Document the different sysfs attributes that exist for PHY devices:
attached_dev, phy_has_fixups, phy_id and phy_interface.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Documentation/ABI/testing/sysfs-class-net-phydev | 36 ++++++++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-net-phydev
diff --git a/Documentation/ABI/testing/sysfs-class-net-phydev b/Documentation/ABI/testing/sysfs-class-net-phydev
new file mode 100644
index 000000000000..c768d5fd8496
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-net-phydev
@@ -0,0 +1,36 @@
+What: /sys/class/mdio_bus/<bus>/<device>/attached_dev
+Date: May 2017
+KernelVersion: 4.13
+Contact: netdev@vger.kernel.org
+Description:
+ Symbolic link to the network device this PHY device is
+ attached to.
+
+What: /sys/class/mdio_bus/<bus>/<device>/phy_has_fixups
+Date: February 2014
+KernelVersion: 3.15
+Contact: netdev@vger.kernel.org
+Description:
+ Boolean value indicating whether the PHY device has
+ any fixups registered against it (phy_register_fixup)
+
+What: /sys/class/mdio_bus/<bus>/<device>/phy_id
+Date: November 2012
+KernelVersion: 3.8
+Contact: netdev@vger.kernel.org
+Description:
+ 32-bit hexadecimal value corresponding to the PHY device's OUI,
+ model and revision number.
+
+What: /sys/class/mdio_bus/<bus>/<device>/phy_interface
+Date: February 2014
+KernelVersion: 3.15
+Contact: netdev@vger.kernel.org
+Description:
+ String value indicating the PHY interface, possible
+ values are:.
+ <empty> (not available), mii, gmii, sgmii, tbi, rev-mii,
+ rmii, rgmii, rgmii-id, rgmii-rxid, rgmii-txid, rtbi, smii
+ xgmii, moca, qsgmii, trgmii, 1000base-x, 2500base-x, rxaui,
+ unknown
+
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next 1/4] net/flow_dissector: add support for dissection of misc ip header fields
From: Tom Herbert @ 2017-05-25 16:22 UTC (permalink / raw)
To: Or Gerlitz
Cc: David S. Miller, Linux Kernel Network Developers, Saeed Mahameed,
Roi Dayan, Paul Blakey
In-Reply-To: <1495718679-20693-2-git-send-email-ogerlitz@mellanox.com>
On Thu, May 25, 2017 at 6:24 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
> Add support for dissection of ip tos and ttl and ipv6 traffic-class
> and hoplimit. Both are dissected into the same struct.
>
> Uses similar call to ip dissection function as with tcp, arp and others.
>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> Reviewed-by: Jiri Pirko <jiri@mellanox.com>
> ---
> include/net/flow_dissector.h | 11 +++++++++++
> net/core/flow_dissector.c | 40 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 51 insertions(+)
>
> diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h
> index efe34eec..e2663e9 100644
> --- a/include/net/flow_dissector.h
> +++ b/include/net/flow_dissector.h
> @@ -165,6 +165,16 @@ struct flow_dissector_key_tcp {
> __be16 flags;
> };
>
> +/**
> + * struct flow_dissector_key_ip:
> + * @tos: tos
> + * @ttl: ttl
> + */
> +struct flow_dissector_key_ip {
> + __u8 tos;
> + __u8 ttl;
> +};
> +
> enum flow_dissector_key_id {
> FLOW_DISSECTOR_KEY_CONTROL, /* struct flow_dissector_key_control */
> FLOW_DISSECTOR_KEY_BASIC, /* struct flow_dissector_key_basic */
> @@ -186,6 +196,7 @@ enum flow_dissector_key_id {
> FLOW_DISSECTOR_KEY_ENC_PORTS, /* struct flow_dissector_key_ports */
> FLOW_DISSECTOR_KEY_MPLS, /* struct flow_dissector_key_mpls */
> FLOW_DISSECTOR_KEY_TCP, /* struct flow_dissector_key_tcp */
> + FLOW_DISSECTOR_KEY_IP, /* struct flow_dissector_key_ip */
>
> FLOW_DISSECTOR_KEY_MAX,
> };
> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> index 5a45943..fc5fc45 100644
> --- a/net/core/flow_dissector.c
> +++ b/net/core/flow_dissector.c
> @@ -367,6 +367,40 @@ __skb_flow_dissect_tcp(const struct sk_buff *skb,
> key_tcp->flags = (*(__be16 *) &tcp_flag_word(th) & htons(0x0FFF));
> }
>
> +static void
> +__skb_flow_dissect_ipv4(const struct sk_buff *skb,
> + struct flow_dissector *flow_dissector,
> + void *target_container, void *data, const struct iphdr *iph)
> +{
> + struct flow_dissector_key_ip *key_ip;
> +
> + if (!dissector_uses_key(flow_dissector, FLOW_DISSECTOR_KEY_IP))
> + return;
> +
> + key_ip = skb_flow_dissector_target(flow_dissector,
> + FLOW_DISSECTOR_KEY_IP,
> + target_container);
> + key_ip->tos = iph->tos;
> + key_ip->ttl = iph->ttl;
In an encapsulation this returns the tos and ttl of the encapsulated
packet. Is that really useful to the caller? Seems more likely that
they need the outer tos and ttl for forwarding.
> +}
> +
> +static void
> +__skb_flow_dissect_ipv6(const struct sk_buff *skb,
> + struct flow_dissector *flow_dissector,
> + void *target_container, void *data, const struct ipv6hdr *iph)
> +{
> + struct flow_dissector_key_ip *key_ip;
> +
> + if (!dissector_uses_key(flow_dissector, FLOW_DISSECTOR_KEY_IP))
> + return;
> +
> + key_ip = skb_flow_dissector_target(flow_dissector,
> + FLOW_DISSECTOR_KEY_IP,
> + target_container);
> + key_ip->tos = ipv6_get_dsfield(iph);
> + key_ip->ttl = iph->hop_limit;
> +}
> +
> /**
> * __skb_flow_dissect - extract the flow_keys struct and return it
> * @skb: sk_buff to extract the flow from, can be NULL if the rest are specified
> @@ -469,6 +503,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> }
> }
>
> + __skb_flow_dissect_ipv4(skb, flow_dissector,
> + target_container, data, iph);
> +
> if (flags & FLOW_DISSECTOR_F_STOP_AT_L3)
> goto out_good;
>
> @@ -514,6 +551,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> goto out_good;
> }
>
> + __skb_flow_dissect_ipv6(skb, flow_dissector,
> + target_container, data, iph);
> +
> if (flags & FLOW_DISSECTOR_F_STOP_AT_L3)
> goto out_good;
>
> --
> 2.3.7
>
^ permalink raw reply
* Re: Alignment in BPF verifier
From: David Miller @ 2017-05-25 16:31 UTC (permalink / raw)
To: daniel; +Cc: ast, ecree, alexei.starovoitov, netdev
In-Reply-To: <5924A938.2090808@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Tue, 23 May 2017 23:27:20 +0200
> On 05/23/2017 09:45 PM, Alexei Starovoitov wrote:
>> On 5/23/17 7:41 AM, Edward Cree wrote:
>>> Hmm, that means that we can't do arithmetic on a
>>> PTR_TO_MAP_VALUE_OR_NULL, we have to convert it to a PTR_TO_MAP_VALUE
>>> first by NULL-checking it. That's probably fine, but I can just about
>>> imagine some compiler optimisation reordering them. Any reason not to
>>> split this out into a different reg->field, rather than overloading
>>> id?
>>
>> 'id' is sort of like 'version' of a pointer and has the same meaning
>> in
>> both cases. How exactly do you see this split?
>
> Also, same id is never reused once generated and later propagated
> through regs. So far we haven't run into this kind of optimization
> from llvm side yet, but others which led to requiring the id marker
> (see 57a09bf0a416). I could imagine it might be needed at some point,
> though where we later transition directly to PTR_TO_MAP_VALUE_ADJ
> after NULL check. Out of curiosity, did you run into it with llvm?
We could handle this issue in find_good_pkt_pointers(), nothing prevents
us from advancing state there for cases like Edward notes above.
^ permalink raw reply
* Re: [PATCHv2 net-next 1/5] net: dsa: mv88e6xxx: Move phy functions into phy.[ch]
From: David Miller @ 2017-05-25 16:35 UTC (permalink / raw)
To: andrew; +Cc: vivien.didelot, netdev
In-Reply-To: <1495573486-31827-2-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Tue, 23 May 2017 23:04:42 +0200
> The upcoming SERDES support will need to make use of PHY functions. Move
> them out into a file of there own. No code changes.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Please unexport mv88e6xxx_phy_page_get and mv88e6xxx_phy_page_put, as noted
by Vivien they are not used outside of phy.c
Thank you.
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] net: phy: Create sysfs reciprocal links for attached_dev/phydev
From: Andrew Lunn @ 2017-05-25 16:42 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, davem
In-Reply-To: <20170525162143.18319-1-f.fainelli@gmail.com>
On Thu, May 25, 2017 at 09:21:40AM -0700, Florian Fainelli wrote:
> Hi David, Andrew,
>
> This patch series addresses a device topology shortcoming where a program
> scanning /sys would not be able to establish a mapping between the network
> device and the PHY device.
>
> In the process it turned out that no PHY device documentation existed for
> sysfs attributes.
>
> Thanks!
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2 net-next 1/2] Documentation: sysfs-class-net-statistics: Clarify rx_bytes and tx_bytes
From: David Miller @ 2017-05-25 16:43 UTC (permalink / raw)
To: andrew; +Cc: f.fainelli, hayeswang, netdev
In-Reply-To: <1495573858-32346-2-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Tue, 23 May 2017 23:10:57 +0200
> Document what is expected for the rx_bytes and tx_bytes statistics in
> /sys/class/net/<device>/statistics. The FCS should be included in the
> statistics. However, since this has been unclear until now, it is
> expected a number of drivers don't. But maybe with time they will.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Precedence has not been very kind to us here.
Also, we really I want drivers doing the simplest thing possible,
which on transmit is:
tx_bytes += skb->len;
Not:
tx_bytes += skb->len + ETH_FCS_LEN;
I understand the problem you're trying to tackle, but software stats
should be for software state, and that state is emphatically skb->len
So if we are to strive for software statistic "consistency" it should
be against the software part of the packet, not the software part
"plus X and Y link layer stuff no visible in the software packet".
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/4] net: phy: marvell: More hidden page changes refactored
From: David Miller @ 2017-05-25 16:46 UTC (permalink / raw)
To: andrew; +Cc: f.fainelli, netdev
In-Reply-To: <1495574697-501-3-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Tue, 23 May 2017 23:24:55 +0200
> EXT_ADDR_PAGE is the same meaning as MII_MARVELL_PHY_PAGE, i.e. change
> page. Replace it will calls to the helpers.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Sorry to ding you on this but...
> @@ -1556,12 +1552,19 @@ static int m88e1121_get_temp(struct phy_device *phydev, long *temp)
> {
> int ret;
> int val;
> + int oldpage;
Reverse christmas tree.
> @@ -1671,12 +1674,19 @@ static const struct hwmon_chip_info m88e1121_hwmon_chip_info = {
> static int m88e1510_get_temp(struct phy_device *phydev, long *temp)
> {
> int ret;
> + int oldpage;
>
> *temp = 0;
Likewise.
> @@ -1696,12 +1706,18 @@ static int m88e1510_get_temp(struct phy_device *phydev, long *temp)
> int m88e1510_get_temp_critical(struct phy_device *phydev, long *temp)
> {
> int ret;
> + int oldpage;
>
> *temp = 0;
Likewise.
> @@ -1724,10 +1740,17 @@ int m88e1510_get_temp_critical(struct phy_device *phydev, long *temp)
> int m88e1510_set_temp_critical(struct phy_device *phydev, long temp)
> {
> int ret;
> + int oldpage;
Likewise.
> @@ -1751,12 +1774,19 @@ int m88e1510_set_temp_critical(struct phy_device *phydev, long temp)
> int m88e1510_get_temp_alarm(struct phy_device *phydev, long *alarm)
> {
> int ret;
> + int oldpage;
Likewise.
Otherwise this patch series looks fine to me.
THanks.
^ permalink raw reply
* Re: [PATCH net-next] tcp: better validation of received ack sequences
From: David Miller @ 2017-05-25 16:48 UTC (permalink / raw)
To: eric.dumazet
Cc: p.fiterau-brostean, netdev, F.Vaandrager, ncardwell, ycheng,
soheil
In-Reply-To: <1495578286.6465.90.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 23 May 2017 15:24:46 -0700
> Add a FLAG_NO_CHALLENGE_ACK so that tcp_rcv_state_process()
> can choose to send a challenge ACK and discard the packet instead
> of wrongly change socket state.
Applied, but the tests end up being double-negatives so it might
have been easier to understand if the flag was a positive rather
than a negative value.
^ permalink raw reply
* Re: [PATCH] net: phy: put genphy_config_init's EXPORT_SYMBOL directly after the function
From: David Miller @ 2017-05-25 16:48 UTC (permalink / raw)
To: u.kleine-koenig; +Cc: andrew, f.fainelli, netdev, kernel
In-Reply-To: <20170523222607.13645-1-u.kleine-koenig@pengutronix.de>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Wed, 24 May 2017 00:26:07 +0200
> Commit af6b6967d6e1 ("net: phy: export genphy_config_init()") introduced
> this EXPORT_SYMBOL and put it after gen10g_soft_reset() instead of
> directly after genphy_config_init. Probably this happend when the patch
> was applied because http://patchwork.ozlabs.org/patch/339622/ looks ok.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next] tcp: better validation of received ack sequences
From: Eric Dumazet @ 2017-05-25 16:50 UTC (permalink / raw)
To: David Miller
Cc: p.fiterau-brostean, netdev, F.Vaandrager, ncardwell, ycheng,
soheil
In-Reply-To: <20170525.124817.1960721450872387047.davem@davemloft.net>
On Thu, 2017-05-25 at 12:48 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 23 May 2017 15:24:46 -0700
>
> > Add a FLAG_NO_CHALLENGE_ACK so that tcp_rcv_state_process()
> > can choose to send a challenge ACK and discard the packet instead
> > of wrongly change socket state.
>
> Applied, but the tests end up being double-negatives so it might
> have been easier to understand if the flag was a positive rather
> than a negative value.
I thought of this (and was in fact one of the patch I sent for internal
review at Google), but this was changing all tcp_ack() calls instead of
a single one ?
Or maybe I am missing some easier way ?
Thanks
^ permalink raw reply
* Re: [PATCH net-next] geneve: fix fill_info when using collect_metadata
From: David Miller @ 2017-05-25 16:51 UTC (permalink / raw)
To: e; +Cc: netdev, pshelar
In-Reply-To: <20170523223727.15307-1-e@erig.me>
From: Eric Garver <e@erig.me>
Date: Tue, 23 May 2017 18:37:27 -0400
> Since 9b4437a5b870 ("geneve: Unify LWT and netdev handling.") fill_info
> does not return UDP_ZERO_CSUM6_RX when using COLLECT_METADATA. This is
> because it uses ip_tunnel_info_af() with the device level info, which is
> not valid for COLLECT_METADATA.
>
> Fix by checking for the presence of the actual sockets.
>
> Fixes: 9b4437a5b870 ("geneve: Unify LWT and netdev handling.")
> Signed-off-by: Eric Garver <e@erig.me>
Please target bug fixes at 'net' not 'net-next' unless the bug only
exists in 'net-next'.
I've applied this to 'net' and queued it up for -stable.
^ permalink raw reply
* Re: [PATCH] net: fix potential null pointer dereference
From: David Miller @ 2017-05-25 16:54 UTC (permalink / raw)
To: garsilva; +Cc: pablo, laforge, osmocom-net-gprs, netdev, linux-kernel
In-Reply-To: <20170523231837.GA9364@embeddedgus>
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Date: Tue, 23 May 2017 18:18:37 -0500
> Add null check to avoid a potential null pointer dereference.
>
> Addresses-Coverity-ID: 1408831
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Applied, thank you.
^ permalink raw reply
* Re: pull request: bluetooth-next 2017-05-23
From: David Miller @ 2017-05-25 16:56 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, netdev
In-Reply-To: <20170524001120.GA3971@x1c.Skamania.guest>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Tue, 23 May 2017 17:11:20 -0700
> Here's the first Bluetooth & 802.15.4 pull request targeting the 4.13
> kernel release.
>
> - Bluetooth 5.0 improvements (Data Length Extensions and alternate PHY)
> - Support for new Intel Bluetooth adapter [[8087:0aaa]
> - Various fixes to ieee802154 code
> - Various fixes to HCI UART code
>
> Please let me know if there are any issues pulling. Thanks.
Pulled into net-next, thanks Johan.
^ permalink raw reply
* Re: [PATCH] net: jme: Remove unused functions
From: David Miller @ 2017-05-25 16:59 UTC (permalink / raw)
To: mka; +Cc: cooldavid, netdev, linux-kernel, dianders
In-Reply-To: <20170524002751.172595-1-mka@chromium.org>
From: Matthias Kaehlcke <mka@chromium.org>
Date: Tue, 23 May 2017 17:27:51 -0700
> The functions jme_restart_tx_engine(), jme_pause_rx() and
> jme_resume_rx() are not used. Removing them fixes the following warnings
> when building with clang:
>
> drivers/net/ethernet/jme.c:694:1: error: unused function
> 'jme_restart_tx_engine' [-Werror,-Wunused-function]
>
> drivers/net/ethernet/jme.c:2393:20: error: unused function
> 'jme_pause_rx' [-Werror,-Wunused-function]
>
> drivers/net/ethernet/jme.c:2406:20: error: unused function
> 'jme_resume_rx' [-Werror,-Wunused-function]
>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Applied to net-next.
^ permalink raw reply
* Re: [RFC] skbuff: introduce skb_put_zero()
From: David Miller @ 2017-05-25 17:01 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
johannes.berg-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20170524070747.18573-1-johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Wed, 24 May 2017 09:07:47 +0200
> From: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> This pattern was introduced a number of times in mac80211 just now,
> and since it's present in a number of other places it makes sense
> to add a little helper for it.
>
> The transformations of all code were done with the following spatch:
>
> @@
> identifier p;
> expression len;
> expression skb;
> @@
> -p = skb_put(skb, len);
> -memset(p, 0, len);
> +p = skb_put_zero(skb, len);
>
> Signed-off-by: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
> NB: the patch won't apply to net-next because a few of the mac80211
> users don't exist there yet
Acked-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
No objections, feel free to push this in via your mac80211 tree.
^ permalink raw reply
* Re: [PATCH v3 0/5] net-next: stmmac: rework the speed selection
From: David Miller @ 2017-05-25 17:08 UTC (permalink / raw)
To: clabbe.montjoie; +Cc: peppe.cavallaro, alexandre.torgue, netdev, linux-kernel
In-Reply-To: <20170524071647.7921-1-clabbe.montjoie@gmail.com>
From: Corentin Labbe <clabbe.montjoie@gmail.com>
Date: Wed, 24 May 2017 09:16:42 +0200
> The current stmmac_adjust_link() part which handle speed have
> some if (has_platform) code and my dwmac-sun8i will add more of them.
>
> So we need to handle better speed selection.
> Moreover the struct link member speed and port are hard to guess their
> purpose. And their unique usage are to be combined for writing speed.
>
> My first try was to create an adjust_link() in stmmac_ops but it duplicate some code
>
> The current solution is to have direct value for 10/100/1000 and a mask for them.
>
> The first 4 patchs fix some minor problem found in stmmac_adjust_link() and reported by Florian Fainelli in my previous serie.
> The last patch is the real work.
>
> This series is tested on cubieboard2 (dwmac1000) and opipc (dwmac-sun8i).
Series applied.
^ permalink raw reply
* Re: [PATCH net-next] net: rps: Add the rfs_needed check when record flow hash
From: David Miller @ 2017-05-25 17:11 UTC (permalink / raw)
To: gfree.wind; +Cc: netdev
In-Reply-To: <1495611359-118199-1-git-send-email-gfree.wind@vip.163.com>
From: gfree.wind@vip.163.com
Date: Wed, 24 May 2017 15:35:59 +0800
>
> +static inline void sock_rps_record_flow_hash(__u32 hash)
> +{
> +#ifdef CONFIG_RPS
> + if (static_key_false(&rfs_needed))
> + _sock_rps_record_flow_hash(hash);
> +#endif
> +}
> +
This is no longer used.
If you have some plans to use it in another context, you absolutely _MUST_
post this change inside of a patch series that adds the new user as well.
Otherwise it is impossible to determine the correctness and
appropriateness of your changes.
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