* Re: [PATCH net-next] net/packet: remove unused parameter in prb_curr_blk_in_use().
From: David Miller @ 2017-05-25 17:19 UTC (permalink / raw)
To: rami.rosen; +Cc: netdev
In-Reply-To: <1495640051-39181-1-git-send-email-rami.rosen@intel.com>
From: Rami Rosen <rami.rosen@intel.com>
Date: Wed, 24 May 2017 18:34:11 +0300
> This patch removes unused parameter from prb_curr_blk_in_use() method
> in net/packet/af_packet.c.
>
> Signed-off-by: Rami Rosen <rami.rosen@intel.com>
Applied.
^ permalink raw reply
* [PATCH net v2] sctp: fix ICMP processing if skb is non-linear
From: Davide Caratti @ 2017-05-25 17:14 UTC (permalink / raw)
To: netdev, linux-sctp; +Cc: Xin Long, Marcelo Ricardo Leitner, David S . Miller
sometimes ICMP replies to INIT chunks are ignored by the client, even if
the encapsulated SCTP headers match an open socket. This happens when the
ICMP packet is carried by a paged skb: use skb_header_pointer() to read
packet contents beyond the SCTP header, so that chunk header and initiate
tag are validated correctly.
v2:
- don't use skb_header_pointer() to read the transport header, since
icmp_socket_deliver() already puts these 8 bytes in the linear area.
- change commit message to make specific reference to INIT chunks.
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sctp/input.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/net/sctp/input.c b/net/sctp/input.c
index 0e06a27..ba9ad32 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -473,15 +473,14 @@ struct sock *sctp_err_lookup(struct net *net, int family, struct sk_buff *skb,
struct sctp_association **app,
struct sctp_transport **tpp)
{
+ struct sctp_init_chunk *chunkhdr, _chunkhdr;
union sctp_addr saddr;
union sctp_addr daddr;
struct sctp_af *af;
struct sock *sk = NULL;
struct sctp_association *asoc;
struct sctp_transport *transport = NULL;
- struct sctp_init_chunk *chunkhdr;
__u32 vtag = ntohl(sctphdr->vtag);
- int len = skb->len - ((void *)sctphdr - (void *)skb->data);
*app = NULL; *tpp = NULL;
@@ -516,13 +515,16 @@ struct sock *sctp_err_lookup(struct net *net, int family, struct sk_buff *skb,
* discard the packet.
*/
if (vtag == 0) {
- chunkhdr = (void *)sctphdr + sizeof(struct sctphdr);
- if (len < sizeof(struct sctphdr) + sizeof(sctp_chunkhdr_t)
- + sizeof(__be32) ||
+ /* chunk header + first 4 octects of init header */
+ chunkhdr = skb_header_pointer(skb, skb_transport_offset(skb) +
+ sizeof(struct sctphdr),
+ sizeof(struct sctp_chunkhdr) +
+ sizeof(__be32), &_chunkhdr);
+ if (!chunkhdr ||
chunkhdr->chunk_hdr.type != SCTP_CID_INIT ||
- ntohl(chunkhdr->init_hdr.init_tag) != asoc->c.my_vtag) {
+ ntohl(chunkhdr->init_hdr.init_tag) != asoc->c.my_vtag)
goto out;
- }
+
} else if (vtag != asoc->c.peer_vtag) {
goto out;
}
--
2.9.4
^ permalink raw reply related
* Re: [PATCH v7 net-next 17/17] net: qualcomm: add QCA7000 UART driver
From: David Miller @ 2017-05-25 17:13 UTC (permalink / raw)
To: stefan.wahren
Cc: robh+dt, mark.rutland, gregkh, jslaby, LinoSanfilippo, kubakici,
devicetree, netdev, linux-serial, linux-kernel
In-Reply-To: <1495618181-1204-1-git-send-email-stefan.wahren@i2se.com>
When you submit a new version of a patch within a patch series, you must
always resubmit the entire series not just the patches which change.
Thank you.
^ permalink raw reply
* Re: [PATCH v2] net: move somaxconn init from sysctl code
From: David Miller @ 2017-05-25 17:12 UTC (permalink / raw)
To: roman.kapl; +Cc: netdev
In-Reply-To: <20170524082222.14208-1-roman.kapl@sysgo.com>
From: Roman Kapl <roman.kapl@sysgo.com>
Date: Wed, 24 May 2017 10:22:22 +0200
> The default value for somaxconn is set in sysctl_core_net_init(), but this
> function is not called when kernel is configured without CONFIG_SYSCTL.
>
> This results in the kernel not being able to accept TCP connections,
> because the backlog has zero size. Usually, the user ends up with:
> "TCP: request_sock_TCP: Possible SYN flooding on port 7. Dropping request. Check SNMP counters."
> If SYN cookies are not enabled the connection is rejected.
>
> Before ef547f2ac16 (tcp: remove max_qlen_log), the effects were less
> severe, because the backlog was always at least eight slots long.
>
> Signed-off-by: Roman Kapl <roman.kapl@sysgo.com>
This looks better, applied, thanks.
^ 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
* 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: [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] 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: 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: 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: [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-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: 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: 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-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 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 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: [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: 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: [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
* [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
* [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 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 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
* 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
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