Netdev List
 help / color / mirror / Atom feed
* 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

* 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 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

* [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 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

* Re: [PATCH net-next] rxrpc: Support network namespacing
From: David Miller @ 2017-05-25 17:20 UTC (permalink / raw)
  To: dhowells; +Cc: netdev, linux-afs, linux-kernel
In-Reply-To: <149564175249.12289.12304563996697291080.stgit@warthog.procyon.org.uk>

From: David Howells <dhowells@redhat.com>
Date: Wed, 24 May 2017 17:02:32 +0100

> Support network namespacing in AF_RXRPC with the following changes:
> 
>  (1) All the local endpoint, peer and call lists, locks, counters, etc. are
>      moved into the per-namespace record.
> 
>  (2) All the connection tracking is moved into the per-namespace record
>      with the exception of the client connection ID tree, which is kept
>      global so that connection IDs are kept unique per-machine.
> 
>  (3) Each namespace gets its own epoch.  This allows each network namespace
>      to pretend to be a separate client machine.
> 
>  (4) The /proc/net/rxrpc_xxx files are now called /proc/net/rxrpc/xxx and
>      the contents reflect the namespace.
> 
> fs/afs/ should be okay with this patch as it explicitly requires the current
> net namespace to be init_net to permit a mount to proceed at the moment.  It
> will, however, need updating so that cells, IP addresses and DNS records are
> per-namespace also.
> 
> Signed-off-by: David Howells <dhowells@redhat.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next] tcp: better validation of received ack sequences
From: David Miller @ 2017-05-25 17:22 UTC (permalink / raw)
  To: eric.dumazet
  Cc: p.fiterau-brostean, netdev, F.Vaandrager, ncardwell, ycheng,
	soheil
In-Reply-To: <1495731051.6465.100.camel@edumazet-glaptop3.roam.corp.google.com>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 25 May 2017 09:50:51 -0700

> 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 ?

Indeed, it is a bit of churn to adjust all callers in order to make
one test easier to read.

I'm not so sure it's better or worth it...

^ permalink raw reply

* Re: [PATCH net-next 2/4] tcp: export do_tcp_sendpages and tcp_rate_check_app_limited functions
From: David Miller @ 2017-05-25 17:26 UTC (permalink / raw)
  To: davejwatson
  Cc: ilyal, aviadye, borisp, liranl, matanb, netdev, tom, herbert,
	linux-crypto, hannes, alexei.starovoitov, nmav, fridolin.pokorny
In-Reply-To: <20170524162657.GA24165@davejwatson-mba.local>

From: Dave Watson <davejwatson@fb.com>
Date: Wed, 24 May 2017 09:26:57 -0700

> Export do_tcp_sendpages and tcp_rate_check_app_limited, since tls will need to
> sendpages while the socket is already locked.
> 
> tcp_sendpage is exported, but requires the socket lock to not be held already.
> 
> Signed-off-by: Aviad Yehezkel <aviadye@mellanox.com>
> Signed-off-by: Ilya Lesokhin <ilyal@mellanox.com>
> Signed-off-by: Boris Pismenny <borisp@mellanox.com>
> Signed-off-by: Dave Watson <davejwatson@fb.com>
 ...
> +EXPORT_SYMBOL(do_tcp_sendpages);
 ...
> +EXPORT_SYMBOL(tcp_rate_check_app_limited);

These need to both be EXPORT_SYMBOL_GPL().

^ permalink raw reply

* Re: [PATCH net-next 0/4] kernel TLS
From: David Miller @ 2017-05-25 17:29 UTC (permalink / raw)
  To: davejwatson
  Cc: ilyal, aviadye, borisp, liranl, matanb, netdev, tom, herbert,
	linux-crypto, hannes, alexei.starovoitov, nmav, fridolin.pokorny
In-Reply-To: <20170524162633.GA24030@davejwatson-mba.local>

From: Dave Watson <davejwatson@fb.com>
Date: Wed, 24 May 2017 09:26:33 -0700

> This series adds support for kernel TLS encryption over TCP sockets.
> A standard TCP socket is converted to a TLS socket using a setsockopt.
> Only symmetric crypto is done in the kernel, as well as TLS record
> framing.  The handshake remains in userspace, and the negotiated
> cipher keys/iv are provided to the TCP socket.
> 
> We implemented support for this API in OpenSSL 1.1.0, the code is
> available at https://github.com/Mellanox/tls-openssl/tree/master
> 
> It should work with any TLS library with similar modifications,
> a test tool using gnutls is here: https://github.com/Mellanox/tls-af_ktls_tool
> 
> Changes from RFC V2:
> 
> * Generic ULP (upper layer protocol) framework instead of TLS specific
>   setsockopts
> * Dropped Mellanox hardware patches, will come as separate series.
>   Framework will work for both.

The value in this is seeing how it can work transparently behind
an existing userspace library providing TLS services.

So the reference to the gnutls and openssl implementations probably
belongs in the Documentation patch #4 too.

Thanks.

^ permalink raw reply

* Re: [PATCH net v2] sctp: fix ICMP processing if skb is non-linear
From: Marcelo Ricardo Leitner @ 2017-05-25 17:29 UTC (permalink / raw)
  To: Davide Caratti; +Cc: netdev, linux-sctp, Xin Long, David S . Miller
In-Reply-To: <d0cd7c2e4b9329ec23e48aed94bf2fbf94554f44.1495730857.git.dcaratti@redhat.com>

On Thu, May 25, 2017 at 07:14:56PM +0200, Davide Caratti wrote:
> 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>

LGTM
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.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
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply

* Re: [PATCH net] tcp: avoid fastopen API to be used on AF_UNSPEC
From: David Miller @ 2017-05-25 17:30 UTC (permalink / raw)
  To: weiwan; +Cc: netdev, ycheng, vegard.nossum, edumazet
In-Reply-To: <20170524165931.22502-1-tracywwnj@gmail.com>

From: Wei Wang <weiwan@google.com>
Date: Wed, 24 May 2017 09:59:31 -0700

> Fastopen API should be used to perform fastopen operations on the TCP
> socket. It does not make sense to use fastopen API to perform disconnect
> by calling it with AF_UNSPEC. The fastopen data path is also prone to
> race conditions and bugs when using with AF_UNSPEC.
> 
> One issue reported and analyzed by Vegard Nossum is as follows:
 ...
> If the connection is reopened then we will send a brand new SYN packet
> after thread A has already queued a buffer. At this point I think the
> socket internal state (sequence numbers etc.) becomes messed up.
> 
> When the new connection is closed, the FIN-ACK is rejected because the
> sequence number is outside the window. The other side tries to
> retransmit,
> but __tcp_retransmit_skb() calls tcp_trim_head() on an empty skb which
> corrupts the skb data length and hits a BUG() in copy_and_csum_bits().
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> Hence, this patch adds a check for AF_UNSPEC in the fastopen data path
> and return EOPNOTSUPP to user if such case happens.
> 
> Fixes: cf60af03ca4e7 ("tcp: Fast Open client - sendmsg(MSG_FASTOPEN)")
> Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
> Signed-off-by: Wei Wang <weiwan@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied and queue up for -stable, thanks.

^ permalink raw reply

* Re: [PATCH] arp: fixed -Wuninitialized compiler warning
From: David Miller @ 2017-05-25 17:38 UTC (permalink / raw)
  To: ihrachys; +Cc: ja, netdev
In-Reply-To: <20170524221935.11167-1-ihrachys@redhat.com>

From: Ihar Hrachyshka <ihrachys@redhat.com>
Date: Wed, 24 May 2017 15:19:35 -0700

> Commit 7d472a59c0e5ec117220a05de6b370447fb6cb66 ("arp: always override
> existing neigh entries with gratuitous ARP") introduced a compiler
> warning:
> 
> net/ipv4/arp.c:880:35: warning: 'addr_type' may be used uninitialized in
> this function [-Wmaybe-uninitialized]
> 
> While the code logic seems to be correct and doesn't allow the variable
> to be used uninitialized, and the warning is not consistently
> reproducible, it's still worth fixing it for other people not to waste
> time looking at the warning in case it pops up in the build environment.
> Yes, compiler is probably at fault, but we will need to accommodate.
> 
> Fixes: 7d472a59c0e5ec117220a05de6b370447fb6cb66
> Signed-off-by: Ihar Hrachyshka <ihrachys@redhat.com>

Applied, but please in the future format your Fixes: tag properly
which should have been:

Fixes: 7d472a59c0e5 ("arp: always override existing neigh entries with gratuitous ARP")

Thanks.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox