* Missed stable line commit (upstream 859828c0ea476b42f3a93d69d117aaba90994b6f)
From: Andrew Collins @ 2014-11-03 22:11 UTC (permalink / raw)
To: netdev@vger.kernel.org, stable, gregkh
I ran into an issue today on latest 3.10 stable line that looks to
have been resolved upstream and tagged for stable:
commit 859828c0ea476b42f3a93d69d117aaba90994b6f
Author: Jiri Pirko <jiri@resnulli.us>
Date: Thu Dec 5 16:27:37 2013 +0100
br: fix use of ->rx_handler_data in code executed on non-rx_handler path
...
Please apply to stable trees as well. Thanks.
The commit did make it into the 3.12 stable line, but seems to have
been missed in 3.10. The commit that causes the issue *did* make it
into 3.10.16 so 3.10 is exposed to the issue:
commit 960b8e5018a552f62cfbc0dfe94be7b6ba178f13
Author: Hong Zhiguo <zhiguohong@tencent.com>
Date: Sat Sep 14 22:42:28 2013 +0800
bridge: fix NULL pointer deref of br_port_get_rcu
[ Upstream commit 716ec052d2280d511e10e90ad54a86f5b5d4dcc2 ]
Any chance 859828c0ea476b42f3a93d69d117aaba90994b6f could be pulled
into the next 3.10 stable?
Thanks,
Andrew Collins
^ permalink raw reply
* Re: [PATCH net-next] net: add rbnode to struct sk_buff
From: Cong Wang @ 2014-11-03 21:41 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, netdev, Yaogong Wang
In-Reply-To: <20141103.163748.929657552226178600.davem@davemloft.net>
On Mon, Nov 3, 2014 at 1:37 PM, David Miller <davem@davemloft.net> wrote:
> From: Cong Wang <cwang@twopensource.com>
> Date: Mon, 3 Nov 2014 13:34:33 -0800
>
>> No objections, but this is hacky, rbnode is larger than ->next + ->prev,
>> this means ->tstamp is always overwritten. This is why netem saves it
>> to its CB. This isn't flexible.
>
> It's the size of next+prev+tstamp. Eric is showing exactly what is
> shared with what with the struct/union layout.
I knew, I meant saving tstamp is not flexible, or at least not pretty. :)
^ permalink raw reply
* Re: [PATCH net-next] net: add rbnode to struct sk_buff
From: David Miller @ 2014-11-03 21:37 UTC (permalink / raw)
To: cwang; +Cc: eric.dumazet, netdev, wygivan
In-Reply-To: <CAHA+R7M0--G=znvqQwy5Qmnm5po9yApcn4LjSSv8+-5c1D7RwQ@mail.gmail.com>
From: Cong Wang <cwang@twopensource.com>
Date: Mon, 3 Nov 2014 13:34:33 -0800
> No objections, but this is hacky, rbnode is larger than ->next + ->prev,
> this means ->tstamp is always overwritten. This is why netem saves it
> to its CB. This isn't flexible.
It's the size of next+prev+tstamp. Eric is showing exactly what is
shared with what with the struct/union layout.
^ permalink raw reply
* Re: TCP NewReno and single retransmit
From: Marcelo Ricardo Leitner @ 2014-11-03 21:35 UTC (permalink / raw)
To: Neal Cardwell; +Cc: Yuchung Cheng, netdev, Eric Dumazet
In-Reply-To: <CADVnQykXpA_A87+bFOCdbb-QLTRf-5TEgspCzE-STO49N+6waw@mail.gmail.com>
On 03-11-2014 18:08, Neal Cardwell wrote:
> On Mon, Nov 3, 2014 at 11:38 AM, Marcelo Ricardo Leitner
> <mleitner@redhat.com> wrote:
>> On 31-10-2014 01:51, Yuchung Cheng wrote:
>>>>>> if (tp->snd_una == tp->high_seq && tcp_is_reno(tp)) {
>>>>>> /* Hold old state until something *above* high_seq
>>>>>> * is ACKed. For Reno it is MUST to prevent false
>>>>>> * fast retransmits (RFC2582). SACK TCP is safe. */
>>>
>>> Or we can just remove this strange state-holding logic?
>>>
>>> I couldn't find such a "MUST" statement in RFC2582. RFC2582 section 3
>>> step 5 suggests exiting the recovery procedure when an ACK acknowledges
>>> the "recover" variable (== tp->high_seq - 1).
>>>
>>> Since we've called tcp_reset_reno_sack() before tcp_try_undo_recovery(),
>>> I couldn't see how false fast retransmits can be triggered without
>>> this state-holding.
>>>
>>> Any insights?
>>
>>
>> Nice one, me neither. Neal?
>
> Since there are no literal IETF-style "MUST" statements in RFC2582, I
> think the "MUST" in the code here is expressing the design philosophy
> behind the author. :-)
>
> AFAICT the "Hold old state" code in tcp_try_undo_recovery() is a
> pretty reasonable implementation of a mechanism specified in NewReno
> RFCs to deal with the fundamental ambiguity between (1) dupacks for
> packets the receiver received above a hole above snd_una, and (2)
> dupacks for spurious retransmits below snd_una. I think the motivation
> behind the "Hold old state" code is to stay in Recovery so that we do
> not treat (2) dupacks as (1) dupacks.
>
> I find RFC 2582 not very clear on this point, and the newest NewReno
> RFC, RFC 6582, is also not so clear IMHO. But the RFC 3782 version of
> NewReno - https://tools.ietf.org/html/rfc3782 - has a reasonable
> discussion of this issue. There is a discussion in
> https://tools.ietf.org/html/rfc3782#section-11
> of this ambiguity:
>
> There are two separate scenarios in which the TCP sender could
> receive three duplicate acknowledgements acknowledging "recover" but
> no more than "recover". One scenario would be that the data sender
> transmitted four packets with sequence numbers higher than "recover",
> that the first packet was dropped in the network, and the following
> three packets triggered three duplicate acknowledgements
> acknowledging "recover". The second scenario would be that the
> sender unnecessarily retransmitted three packets below "recover", and
> that these three packets triggered three duplicate acknowledgements
> acknowledging "recover". In the absence of SACK, the TCP sender is
> unable to distinguish between these two scenarios.
>
> AFAICT RFC 3782 uses the term "recover" for the sequence number Linux
> calls tp->high_seq. The specification in RFC 3782 Sec 3 -
> https://tools.ietf.org/html/rfc3782#section-3 - of the criteria for
> entering Fast Recovery say that we shouldn't go into a new recovery if
> the cumulative ACK field doesn't cover more than high_seq/"recover":
>
> 1) Three duplicate ACKs:
> When the third duplicate ACK is received and the sender is not
> already in the Fast Recovery procedure, check to see if the
> Cumulative Acknowledgement field covers more than "recover". If
> so, go to Step 1A. Otherwise, go to Step 1B.
>
> 1A) Invoking Fast Retransmit:
> ...
> In addition, record the highest sequence number transmitted in
> the variable "recover", and go to Step 2.
>
> 1B) Not invoking Fast Retransmit:
> ...
>
> The last few slides of this presentation by Sally Floyd also talk
> about this point:
>
> http://www.icir.org/floyd/talks/newreno-Mar03.pdf
So by sticking with the recovery for a bit longer will help disambiguate the 3
dupacks on high_seq, if they ever happen, and with that avoid re-entering Fast
Retransmit if initial (2) happen. It's at the cost of leaving the fast
retransmit an ack later but if (2) happens the impact would be much worse, AFAICS.
Cool, thanks Neal. If Yuchung is okay with it, I'll proceed with just zeroing
that tstamp as initially proposed.
Marcelo
^ permalink raw reply
* Re: [PATCH bluetooth-next] netdevice: add ieee802154_ptr to net_device
From: Marcel Holtmann @ 2014-11-03 21:35 UTC (permalink / raw)
To: David S. Miller
Cc: Alexander Aring, linux-wpan-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141103.122024.541066618529355652.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Hi Alex,
>> This patch adds an ieee802154_ptr to the net_device structure.
>> Furthermore the 802.15.4 subsystem will introduce a nl802154 framework
>> which is similar like the nl80211 framework and a wpan_dev structure.
>> The wpan_dev structure will hold additional net_device attributes like
>> address options which are 802.15.4 specific. In the upcoming nl802154
>> implementation we will introduce a NL802154_FLAG_NEED_WPAN_DEV like
>> NL80211_FLAG_NEED_WDEV. For this flag an ieee802154_ptr in net_device is
>> needed. Additional we can access the wpan_dev attributes in upper layers
>> like IEEE 802.15.4 6LoWPAN easily. Current solution is a complicated
>> callback interface and getting these values over subif data structure
>> in mac802154.
>>
>> Signed-off-by: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> No objections, and you can merge this via the bluetooth tree:
>
> Acked-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
patch has been applied to bluetooth-next tree.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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] net: add rbnode to struct sk_buff
From: Cong Wang @ 2014-11-03 21:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Yaogong Wang
In-Reply-To: <1415031593.14083.25.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, Nov 3, 2014 at 8:19 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> struct sk_buff {
> - /* These two members must be first. */
> - struct sk_buff *next;
> - struct sk_buff *prev;
> -
> union {
> - ktime_t tstamp;
> - struct skb_mstamp skb_mstamp;
> + struct {
> + /* These two members must be first. */
> + struct sk_buff *next;
> + struct sk_buff *prev;
> +
> + union {
> + ktime_t tstamp;
> + struct skb_mstamp skb_mstamp;
> + };
> + };
> + struct rb_node rbnode; /* used in netem & tcp stack */
> };
No objections, but this is hacky, rbnode is larger than ->next + ->prev,
this means ->tstamp is always overwritten. This is why netem saves it
to its CB. This isn't flexible.
Maybe both netem and TCP ooo queue should consider CB? Not sure
if TCP still has any space for more CB though.
^ permalink raw reply
* Re: [PATCH net-next 0/7] gue: Remote checksum offload
From: Jesse Gross @ 2014-11-03 21:26 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, netdev
In-Reply-To: <1414882683-25484-1-git-send-email-therbert@google.com>
On Sat, Nov 1, 2014 at 3:57 PM, Tom Herbert <therbert@google.com> wrote:
> This patch set implements remote checksum offload for
> GUE, which is a mechanism that provides checksum offload of
> encapsulated packets using rudimentary offload capabilities found in
> most Network Interface Card (NIC) devices. The outer header checksum
> for UDP is enabled in packets and, with some additional meta
> information in the GUE header, a receiver is able to deduce the
> checksum to be set for an inner encapsulated packet. Effectively this
> offloads the computation of the inner checksum. Enabling the outer
> checksum in encapsulation has the additional advantage that it covers
> more of the packet than the inner checksum including the encapsulation
> headers.
Tom, I have a pretty hard time squaring this with your previous
comments on hardware offload. This looks almost identical to a
protocol-specific hardware offload to me in terms of the implications
on the stack. It actually is more invasive and less likely to scale
across protocols, so the relative cost/benefit doesn't really add up
in my mind.
^ permalink raw reply
* Re: [PATCH net-next] net: add rbnode to struct sk_buff
From: David Miller @ 2014-11-03 21:12 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, wygivan
In-Reply-To: <1415031593.14083.25.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 03 Nov 2014 08:19:53 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Yaogong replaces TCP out of order receive queue by an RB tree.
>
> As netem already does a private skb->{next/prev/tstamp} union
> with a 'struct rb_node', lets do this in a cleaner way.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
This looks fine, and I'll apply it, thanks.
^ permalink raw reply
* Re: [PATCH 1/7] can: m_can: fix possible sleep in napi poll
From: Oliver Hartkopp @ 2014-11-03 21:12 UTC (permalink / raw)
To: Marc Kleine-Budde, Dong Aisheng, linux-can
Cc: wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <5457EA62.5040906@pengutronix.de>
On 11/03/2014 09:49 PM, Marc Kleine-Budde wrote:
> On 11/03/2014 07:37 PM, Oliver Hartkopp wrote:
>> If possible I would suggest to push all 7 patches via can/master as it is
>> pretty bad to say "M_CAN was introduced in 3.18 but M_CAN with CAN FD is
>> working since 3.19".
>
> Sorry, probably not, as CAN FD is a new feature. However we may talk to
> David, as the m_can driver was introduced in 3.18 anyways, so it's
> unlikely to break anything with this patch.
>
Yes. It's just to be 'feature complete' for the FD enabled M_CAN driver.
Hopefully it's ok for Dave ...
Thanks,
Oliver
^ permalink raw reply
* Re: [net-next 00/11][pull request] Intel Wired LAN Driver Updates 2014-11-03
From: David Miller @ 2014-11-03 21:10 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1415026599-16232-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 3 Nov 2014 06:56:28 -0800
> This series contains updates to i40e and i40evf.
...
> The following are changes since commit 55b42b5ca2dcf143465968697fe6c6503b05fca1:
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Pulled, thanks a lot Jeff.
^ permalink raw reply
* Re: [PATCH net] sfc: don't BUG_ON efx->max_channels == 0 in probe
From: David Miller @ 2014-11-03 20:58 UTC (permalink / raw)
To: ecree; +Cc: netdev, sshah, linux-net-drivers
In-Reply-To: <alpine.LFD.2.03.1411031409100.24185@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Mon, 3 Nov 2014 14:14:35 +0000
> efx_ef10_probe() was BUGging out if the BAR2 size was 0. This is
> unnecessarily violent; instead we should just fail to probe the device.
> Kept a WARN_ON as this problem indicates a broken or misconfigured NIC.
>
> Signed-off-by: Edward Cree <ecree@solarflare.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 5/5] stmmac: pci: remove FSF address
From: David Miller @ 2014-11-03 20:57 UTC (permalink / raw)
To: andriy.shevchenko
Cc: peppe.cavallaro, netdev, hock.leong.kweh, vbridgers2013, rayagond
In-Reply-To: <1415019737-32736-6-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon, 3 Nov 2014 15:02:17 +0200
> The FSF address is subject to change, thus remove it from the file.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
I cound 90t instances of this under drivers/net, therefore if this change is
appropriate I'd rather someone script this and kill it across entire
subdirectories.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/3] RDMA/cxgb4,cxgb4vf,cxgb4i,csiostor: Cleanup macros
From: David Miller @ 2014-11-03 20:51 UTC (permalink / raw)
To: hariprasad
Cc: netdev, linux-rdma, linux-scsi, roland, JBottomley, hch, swise,
leedom, anish, praveenm, nirranjan, kumaras
In-Reply-To: <1415017014-12701-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Mon, 3 Nov 2014 17:46:51 +0530
> This series moves the debugfs code to a new file debugfs.c, Cleans up macros so
> that they match the hardware generated one.
How does "hardware generate the macros"?
I don't understand what this means at all.
Whatever your better explanation is, you'll have include it in a respun
version of this patch series.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/7] can: m_can: fix possible sleep in napi poll
From: Marc Kleine-Budde @ 2014-11-03 20:49 UTC (permalink / raw)
To: Oliver Hartkopp, Dong Aisheng, linux-can
Cc: wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <5457CB6B.3080002@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On 11/03/2014 07:37 PM, Oliver Hartkopp wrote:
> you can omit the 'stable' tag as this driver just emerged in 3.18 - which is
> currently in 3.18-rc3 state.
Thanks! fixed.
> If possible I would suggest to push all 7 patches via can/master as it is
> pretty bad to say "M_CAN was introduced in 3.18 but M_CAN with CAN FD is
> working since 3.19".
Sorry, probably not, as CAN FD is a new feature. However we may talk to
David, as the m_can driver was introduced in 3.18 anyways, so it's
unlikely to break anything with this patch.
> This will produce confusion as the M_CAN core has built-in CAN FD support.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 5/7] can: clear ctrlmode when close candev
From: Marc Kleine-Budde @ 2014-11-03 20:47 UTC (permalink / raw)
To: Dong Aisheng, linux-can
Cc: wg, varkabhadram, netdev, socketcan, linux-arm-kernel
In-Reply-To: <1414579527-31100-5-git-send-email-b29396@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]
On 10/29/2014 11:45 AM, Dong Aisheng wrote:
> Currently priv->ctrlmode is not cleared when close_candev, so next time
> the driver will still use this value to set controller even user
> does not set any ctrl mode.
> e.g.
> Step 1. ip link set can0 up type can0 bitrate 1000000 loopback on
> Controller will be in loopback mode
> Step 2. ip link set can0 down
> Step 3. ip link set can0 up type can0 bitrate 1000000
> Controller will still be set to loopback mode in driver due to saved
> priv->ctrlmode.
>
> This patch clears priv->ctrlmode when the CAN interface is closed,
> and set it to correct mode according to next user setting.
>
> Signed-off-by: Dong Aisheng <b29396@freescale.com>
NACK, as discussed with Oliver.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] uapi: resort Kbuild entries
From: David Miller @ 2014-11-03 20:45 UTC (permalink / raw)
To: stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ
Cc: gregkh-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141103124234.77377274@urahara>
From: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
Date: Mon, 3 Nov 2014 12:42:34 -0800
> The entries in the Kbuild files are incorrectly sorted.
> Matters for aesthetics only.
>
> Signed-off-by: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
>
> ---
> Patch against -net tree since that is where my last change was.
As such, I'll apply to this to net-next after my next merge.
^ permalink raw reply
* Re: [PATCH net 0/4] ipv6: Fix iflink setting for ipv6 tunnels
From: David Miller @ 2014-11-03 20:43 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev
In-Reply-To: <1415002770-5797-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon, 3 Nov 2014 09:19:26 +0100
> The ipv6 tunnels do the dev->iflink setting too early, it gets
> overwritten by register_netdev(). So set dev->iflink from within
> a ndo_init function to keep the configured setting.
>
> This patchset fixes this for ip6_tunnel, vti6, sit and gre6.
Series applied, good catch, and thanks for checking all of the ipv6
tunnel drivers for this problem.
^ permalink raw reply
* [PATCH] uapi: resort Kbuild entries
From: Stephen Hemminger @ 2014-11-03 20:42 UTC (permalink / raw)
To: David Miller, Greg KH; +Cc: netdev, linux-api
The entries in the Kbuild files are incorrectly sorted.
Matters for aesthetics only.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
Patch against -net tree since that is where my last change was.
--- a/include/uapi/linux/Kbuild 2014-11-02 11:24:32.304658688 -0800
+++ b/include/uapi/linux/Kbuild 2014-11-02 11:27:09.017509917 -0800
@@ -37,27 +37,27 @@ header-y += aio_abi.h
header-y += apm_bios.h
header-y += arcfb.h
header-y += atalk.h
-header-y += atm.h
-header-y += atm_eni.h
-header-y += atm_he.h
-header-y += atm_idt77105.h
-header-y += atm_nicstar.h
-header-y += atm_tcp.h
-header-y += atm_zatm.h
header-y += atmapi.h
header-y += atmarp.h
header-y += atmbr2684.h
header-y += atmclip.h
header-y += atmdev.h
+header-y += atm_eni.h
+header-y += atm.h
+header-y += atm_he.h
+header-y += atm_idt77105.h
header-y += atmioc.h
header-y += atmlec.h
header-y += atmmpc.h
+header-y += atm_nicstar.h
header-y += atmppp.h
header-y += atmsap.h
header-y += atmsvc.h
+header-y += atm_tcp.h
+header-y += atm_zatm.h
header-y += audit.h
-header-y += auto_fs.h
header-y += auto_fs4.h
+header-y += auto_fs.h
header-y += auxvec.h
header-y += ax25.h
header-y += b1lli.h
@@ -67,8 +67,8 @@ header-y += bfs_fs.h
header-y += binfmts.h
header-y += blkpg.h
header-y += blktrace_api.h
-header-y += bpf.h
header-y += bpf_common.h
+header-y += bpf.h
header-y += bpqether.h
header-y += bsg.h
header-y += btrfs.h
@@ -93,21 +93,21 @@ header-y += cyclades.h
header-y += cycx_cfm.h
header-y += dcbnl.h
header-y += dccp.h
-header-y += dlm.h
+header-y += dlmconstants.h
header-y += dlm_device.h
+header-y += dlm.h
header-y += dlm_netlink.h
header-y += dlm_plock.h
-header-y += dlmconstants.h
header-y += dm-ioctl.h
header-y += dm-log-userspace.h
header-y += dn.h
header-y += dqblk_xfs.h
header-y += edd.h
header-y += efs_fs_sb.h
+header-y += elfcore.h
header-y += elf-em.h
header-y += elf-fdpic.h
header-y += elf.h
-header-y += elfcore.h
header-y += errno.h
header-y += errqueue.h
header-y += ethtool.h
@@ -131,15 +131,15 @@ header-y += fsl_hypervisor.h
header-y += fuse.h
header-y += futex.h
header-y += gameport.h
-header-y += gen_stats.h
header-y += genetlink.h
+header-y += gen_stats.h
header-y += gfs2_ondisk.h
header-y += gigaset_dev.h
-header-y += hdlc.h
header-y += hdlcdrv.h
+header-y += hdlc.h
header-y += hdreg.h
-header-y += hid.h
header-y += hiddev.h
+header-y += hid.h
header-y += hidraw.h
header-y += hpet.h
header-y += hsr_netlink.h
@@ -151,7 +151,6 @@ header-y += i2o-dev.h
header-y += i8k.h
header-y += icmp.h
header-y += icmpv6.h
-header-y += if.h
header-y += if_addr.h
header-y += if_addrlabel.h
header-y += if_alg.h
@@ -165,6 +164,7 @@ header-y += if_ether.h
header-y += if_fc.h
header-y += if_fddi.h
header-y += if_frad.h
+header-y += if.h
header-y += if_hippi.h
header-y += if_infiniband.h
header-y += if_link.h
@@ -182,40 +182,40 @@ header-y += if_tunnel.h
header-y += if_vlan.h
header-y += if_x25.h
header-y += igmp.h
-header-y += in.h
header-y += in6.h
-header-y += in_route.h
header-y += inet_diag.h
+header-y += in.h
header-y += inotify.h
header-y += input.h
+header-y += in_route.h
header-y += ioctl.h
-header-y += ip.h
header-y += ip6_tunnel.h
-header-y += ip_vs.h
header-y += ipc.h
+header-y += ip.h
header-y += ipmi.h
header-y += ipmi_msgdefs.h
header-y += ipsec.h
header-y += ipv6.h
header-y += ipv6_route.h
+header-y += ip_vs.h
header-y += ipx.h
header-y += irda.h
header-y += irqnr.h
-header-y += isdn.h
header-y += isdn_divertif.h
-header-y += isdn_ppp.h
+header-y += isdn.h
header-y += isdnif.h
+header-y += isdn_ppp.h
header-y += iso_fs.h
-header-y += ivtv.h
header-y += ivtvfb.h
+header-y += ivtv.h
header-y += ixjuser.h
header-y += jffs2.h
header-y += joystick.h
-header-y += kd.h
header-y += kdev_t.h
-header-y += kernel-page-flags.h
-header-y += kernel.h
+header-y += kd.h
header-y += kernelcapi.h
+header-y += kernel.h
+header-y += kernel-page-flags.h
header-y += kexec.h
header-y += keyboard.h
header-y += keyctl.h
@@ -231,6 +231,7 @@ ifneq ($(wildcard $(srctree)/arch/$(SRCA
header-y += kvm_para.h
endif
+header-y += hw_breakpoint.h
header-y += l2tp.h
header-y += libc-compat.h
header-y += limits.h
@@ -255,43 +256,43 @@ header-y += mman.h
header-y += mmtimer.h
header-y += mpls.h
header-y += mqueue.h
-header-y += mroute.h
header-y += mroute6.h
+header-y += mroute.h
header-y += msdos_fs.h
header-y += msg.h
header-y += mtio.h
-header-y += n_r3964.h
header-y += nbd.h
-header-y += ncp.h
header-y += ncp_fs.h
+header-y += ncp.h
header-y += ncp_mount.h
header-y += ncp_no.h
header-y += neighbour.h
-header-y += net.h
-header-y += net_dropmon.h
-header-y += net_tstamp.h
header-y += netconf.h
header-y += netdevice.h
-header-y += netlink_diag.h
-header-y += netfilter.h
+header-y += net_dropmon.h
header-y += netfilter_arp.h
header-y += netfilter_bridge.h
header-y += netfilter_decnet.h
+header-y += netfilter.h
header-y += netfilter_ipv4.h
header-y += netfilter_ipv6.h
+header-y += net.h
+header-y += netlink_diag.h
header-y += netlink.h
header-y += netrom.h
+header-y += net_tstamp.h
header-y += nfc.h
-header-y += nfs.h
header-y += nfs2.h
header-y += nfs3.h
header-y += nfs4.h
header-y += nfs4_mount.h
+header-y += nfsacl.h
header-y += nfs_fs.h
+header-y += nfs.h
header-y += nfs_idmap.h
header-y += nfs_mount.h
-header-y += nfsacl.h
header-y += nl80211.h
+header-y += n_r3964.h
header-y += nubus.h
header-y += nvme.h
header-y += nvram.h
@@ -311,16 +312,16 @@ header-y += pfkeyv2.h
header-y += pg.h
header-y += phantom.h
header-y += phonet.h
+header-y += pktcdvd.h
header-y += pkt_cls.h
header-y += pkt_sched.h
-header-y += pktcdvd.h
header-y += pmu.h
header-y += poll.h
header-y += posix_types.h
header-y += ppdev.h
header-y += ppp-comp.h
-header-y += ppp-ioctl.h
header-y += ppp_defs.h
+header-y += ppp-ioctl.h
header-y += pps.h
header-y += prctl.h
header-y += psci.h
@@ -352,13 +353,13 @@ header-y += seccomp.h
header-y += securebits.h
header-y += selinux_netlink.h
header-y += sem.h
-header-y += serial.h
header-y += serial_core.h
+header-y += serial.h
header-y += serial_reg.h
header-y += serio.h
header-y += shm.h
-header-y += signal.h
header-y += signalfd.h
+header-y += signal.h
header-y += smiapp.h
header-y += snmp.h
header-y += sock_diag.h
@@ -367,8 +368,8 @@ header-y += sockios.h
header-y += som.h
header-y += sonet.h
header-y += sonypi.h
-header-y += sound.h
header-y += soundcard.h
+header-y += sound.h
header-y += stat.h
header-y += stddef.h
header-y += string.h
@@ -387,11 +388,11 @@ header-y += time.h
header-y += times.h
header-y += timex.h
header-y += tiocl.h
-header-y += tipc.h
header-y += tipc_config.h
+header-y += tipc.h
header-y += toshiba.h
-header-y += tty.h
header-y += tty_flags.h
+header-y += tty.h
header-y += types.h
header-y += udf_fs_i.h
header-y += udp.h
@@ -437,6 +438,5 @@ header-y += wireless.h
header-y += x25.h
header-y += xattr.h
header-y += xfrm.h
-header-y += hw_breakpoint.h
header-y += zorro.h
header-y += zorro_ids.h
^ permalink raw reply
* Re: [PATCH] hamradio: 6pack: remove unnecessary check
From: David Miller @ 2014-11-03 20:34 UTC (permalink / raw)
To: sudipm.mukherjee; +Cc: ajk, linux-hams, netdev, linux-kernel
In-Reply-To: <1415016749-6825-1-git-send-email-sudipm.mukherjee@gmail.com>
From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Date: Mon, 3 Nov 2014 17:42:29 +0530
> this is check for dev is unnecessary, as we are already checking dev
> after allocating it via alloc_netdev, and jumping to label: out
> if it is NULL.
>
> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
From: David Miller @ 2014-11-03 20:29 UTC (permalink / raw)
To: alexei.starovoitov; +Cc: felix, kda, netdev, linuxppc-dev, mpe, matt
In-Reply-To: <CAADnVQJYNB15cQvDi0+AcL==n+f8PAb1=Dnp_vBWku4SA-Q_6Q@mail.gmail.com>
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Mon, 3 Nov 2014 09:21:03 -0800
> On Mon, Nov 3, 2014 at 9:06 AM, David Miller <davem@davemloft.net> wrote:
>> From: Denis Kirjanov <kda@linux-powerpc.org>
>> Date: Thu, 30 Oct 2014 09:12:15 +0300
>>
>>> Add BPF extension SKF_AD_PKTTYPE to ppc JIT to load
>>> skb->pkt_type field.
>>>
>>> Before:
>>> [ 88.262622] test_bpf: #11 LD_IND_NET 86 97 99 PASS
>>> [ 88.265740] test_bpf: #12 LD_PKTTYPE 109 107 PASS
>>>
>>> After:
>>> [ 80.605964] test_bpf: #11 LD_IND_NET 44 40 39 PASS
>>> [ 80.607370] test_bpf: #12 LD_PKTTYPE 9 9 PASS
>>>
>>> CC: Alexei Starovoitov<alexei.starovoitov@gmail.com>
>>> CC: Michael Ellerman<mpe@ellerman.id.au>
>>> Cc: Matt Evans <matt@ozlabs.org>
>>> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
>>>
>>> v2: Added test rusults
>>
>> So, can I apply this now?
>
> I think this question is more towards ppc folks,
> since both Daniel and myself said before that it looks ok.
> Philippe just tested the previous version of this patch on ppc64le...
> I'm guessing that Matt (original author of bpf jit for ppc) is not replying,
> because he has no objections.
> Either way the addition is tiny and contained, so can go in now.
Ok, I have applied this to net-next, thanks everyone.
^ permalink raw reply
* Re: [PATCH] VNIC: Adding support for Cavium ThunderX network controller
From: Stephen Hemminger @ 2014-11-03 20:25 UTC (permalink / raw)
To: Robert Richter
Cc: Sunil Kovvuri, Robert Richter, David S. Miller, Sunil Goutham,
Stefan Assmann, LKML, LAKML, netdev
In-Reply-To: <20141103183345.GK31556@rric.localhost>
On Mon, 3 Nov 2014 19:33:45 +0100
Robert Richter <robert.richter@caviumnetworks.com> wrote:
> On 03.11.14 10:16:51, Stephen Hemminger wrote:
> > On Fri, 31 Oct 2014 22:44:11 +0530
> > Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:
> >
> > > On Fri, Oct 31, 2014 at 8:24 AM, Stephen Hemminger
> > > <stephen@networkplumber.org> wrote:
> > > > On Thu, 30 Oct 2014 17:54:34 +0100
> > > > Robert Richter <rric@kernel.org> wrote:
> > > >
> > > >> +#ifdef VNIC_RSS_SUPPORT
> > > >> +static int rss_config = RSS_IP_HASH_ENA | RSS_TCP_HASH_ENA | RSS_UDP_HASH_ENA;
> > > >> +module_param(rss_config, int, S_IRUGO);
> > > >> +MODULE_PARM_DESC(rss_config,
> > > >> + "RSS hash config [bits 8:0] (Bit0:L2 extended, 1:IP, 2:TCP, 3:TCP SYN, 4:UDP, 5:L4 extended, 6:ROCE 7:L3 bi-directional, 8:L4 bi-directional)");
> > > >> +#endif
> > > >
> > > > This should managed be via ethtool ETHTOOL_GRXFH rather than a module parameter.
> > > Thanks, i will add setting hash options via ETHTOOL_SRXFH as well.
> > > The idea here is to have a choice of hash while module load (through
> > > module params) and if it needs to be changed runtime then
> > > via Ethtool.
> > >
> > > Sunil.
> >
> > Network developers do not like vendor unique module parameters.
> > Anything device specific doesn't work in a generic distro environment.
>
> Do you accept unique module parameters in parallel to ethtool support
> or should this be removed?
If there is ethtool support the module parameters are not needed.
Unneeded code is to be avoided.
^ permalink raw reply
* Re: [PATCH net-next 3/7] gue: Add infrastructure for flags and options
From: David Miller @ 2014-11-03 20:12 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <CA+mtBx8QZn8M8mnU84w2+sc4bt98kf-_SuW0jz15qYNX21vCag@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Mon, 3 Nov 2014 10:39:14 -0800
> On Mon, Nov 3, 2014 at 9:18 AM, David Miller <davem@davemloft.net> wrote:
>> From: Tom Herbert <therbert@google.com>
>> Date: Sat, 1 Nov 2014 15:57:59 -0700
>>
>>> @@ -20,7 +20,16 @@ static size_t fou_encap_hlen(struct ip_tunnel_encap *e)
>>>
>>> static size_t gue_encap_hlen(struct ip_tunnel_encap *e)
>>> {
>>> - return sizeof(struct udphdr) + sizeof(struct guehdr);
>>> + size_t len;
>>> + bool need_priv = false;
>>> +
>>> + len = sizeof(struct udphdr) + sizeof(struct guehdr);
>>> +
>>> + /* Add in lengths flags */
>>> +
>>> + len += need_priv ? GUE_LEN_PRIV : 0;
>>
>> Add this need_priv logic in patch #6, not here.
>
> I would rather keep it in this patch. This is adding the common
> infrastructure to support private option field, remote checksum
> offload is an instance that uses that.
Tom, it evaluates always to a constant boolean, and contextually makes
no sense to someone reviewing this change in isolation.
Please, as I have asked, put this in the patch where the logic
actually matters.
^ permalink raw reply
* Re: [stable request <= 3.11] net/mlx4_en: Fix BlueFlame race
From: David Miller @ 2014-11-03 20:09 UTC (permalink / raw)
To: cwang; +Cc: ben, vlee, amirv, ogerlitz, jackm, eugenia, matanb, netdev
In-Reply-To: <CAHA+R7OMgOpnWyy5E55OtLS4naOcZ5EhzViE14Yffu=K=TqNcA@mail.gmail.com>
From: Cong Wang <cwang@twopensource.com>
Date: Mon, 3 Nov 2014 09:22:18 -0800
> On Sat, Nov 1, 2014 at 10:41 AM, David Miller <davem@davemloft.net> wrote:
>>
>> There is no documented way nor do I wish to state anything so strictly.
>> I want maximum flexibility for such a time consuming task.
>>
>> I tend to go back 3 or 4 releases at most, and it really depends upon
>> the difficulty of the backports and my own time constraints.
>
> You should really offload to developers, otherwise too much work for you. :)
That's exactly what I am doing by having the -stable maintainers for older
releases deal with the backports and other pains.
^ permalink raw reply
* Re: TCP NewReno and single retransmit
From: Neal Cardwell @ 2014-11-03 20:08 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: Yuchung Cheng, netdev, Eric Dumazet
In-Reply-To: <5457AF6D.6010105@redhat.com>
On Mon, Nov 3, 2014 at 11:38 AM, Marcelo Ricardo Leitner
<mleitner@redhat.com> wrote:
> On 31-10-2014 01:51, Yuchung Cheng wrote:
>>>>> if (tp->snd_una == tp->high_seq && tcp_is_reno(tp)) {
>>>>> /* Hold old state until something *above* high_seq
>>>>> * is ACKed. For Reno it is MUST to prevent false
>>>>> * fast retransmits (RFC2582). SACK TCP is safe. */
>>
>> Or we can just remove this strange state-holding logic?
>>
>> I couldn't find such a "MUST" statement in RFC2582. RFC2582 section 3
>> step 5 suggests exiting the recovery procedure when an ACK acknowledges
>> the "recover" variable (== tp->high_seq - 1).
>>
>> Since we've called tcp_reset_reno_sack() before tcp_try_undo_recovery(),
>> I couldn't see how false fast retransmits can be triggered without
>> this state-holding.
>>
>> Any insights?
>
>
> Nice one, me neither. Neal?
Since there are no literal IETF-style "MUST" statements in RFC2582, I
think the "MUST" in the code here is expressing the design philosophy
behind the author. :-)
AFAICT the "Hold old state" code in tcp_try_undo_recovery() is a
pretty reasonable implementation of a mechanism specified in NewReno
RFCs to deal with the fundamental ambiguity between (1) dupacks for
packets the receiver received above a hole above snd_una, and (2)
dupacks for spurious retransmits below snd_una. I think the motivation
behind the "Hold old state" code is to stay in Recovery so that we do
not treat (2) dupacks as (1) dupacks.
I find RFC 2582 not very clear on this point, and the newest NewReno
RFC, RFC 6582, is also not so clear IMHO. But the RFC 3782 version of
NewReno - https://tools.ietf.org/html/rfc3782 - has a reasonable
discussion of this issue. There is a discussion in
https://tools.ietf.org/html/rfc3782#section-11
of this ambiguity:
There are two separate scenarios in which the TCP sender could
receive three duplicate acknowledgements acknowledging "recover" but
no more than "recover". One scenario would be that the data sender
transmitted four packets with sequence numbers higher than "recover",
that the first packet was dropped in the network, and the following
three packets triggered three duplicate acknowledgements
acknowledging "recover". The second scenario would be that the
sender unnecessarily retransmitted three packets below "recover", and
that these three packets triggered three duplicate acknowledgements
acknowledging "recover". In the absence of SACK, the TCP sender is
unable to distinguish between these two scenarios.
AFAICT RFC 3782 uses the term "recover" for the sequence number Linux
calls tp->high_seq. The specification in RFC 3782 Sec 3 -
https://tools.ietf.org/html/rfc3782#section-3 - of the criteria for
entering Fast Recovery say that we shouldn't go into a new recovery if
the cumulative ACK field doesn't cover more than high_seq/"recover":
1) Three duplicate ACKs:
When the third duplicate ACK is received and the sender is not
already in the Fast Recovery procedure, check to see if the
Cumulative Acknowledgement field covers more than "recover". If
so, go to Step 1A. Otherwise, go to Step 1B.
1A) Invoking Fast Retransmit:
...
In addition, record the highest sequence number transmitted in
the variable "recover", and go to Step 2.
1B) Not invoking Fast Retransmit:
...
The last few slides of this presentation by Sally Floyd also talk
about this point:
http://www.icir.org/floyd/talks/newreno-Mar03.pdf
neal
^ permalink raw reply
* Re: [0/3] net: Kill skb_copy_datagram_const_iovec
From: David Miller @ 2014-11-03 20:05 UTC (permalink / raw)
To: herbert; +Cc: viro, netdev, linux-kernel, bcrl
In-Reply-To: <20141103053751.GA27845@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 3 Nov 2014 13:37:51 +0800
> On Mon, Nov 03, 2014 at 12:45:03AM +0000, Al Viro wrote:
>>
>> Note, BTW, that there's a damn good reason to convert the socket side of
>> things to iov_iter - as it is, ->splice_write() there is basically done with
>> page-by-page mapping and doing kernel_sendmsg(); being able to deal with
>> "map and copy" stuff *inside* ->sendmsg() would not only reduce the overhead,
>> it would allow to get rid of ->sendpage() completely. Basically, let
>> ->sendmsg() instances check the iov_iter type and play zerocopy games if
>> it's an "array of kernel pages" kind. Compare ->sendpage() and ->sendmsg()
>> instances for the protocols that have nontrivial ->sendpage(); you'll see
>> that there's a lot of duplication. Merging them looks very feasible, with
>> divergence happening only very deep in the call chain.
>
> Honestly I don't really care which way we end up going as long as
> we pick one solution and stick with it. Right now we have an
> abomination in the form of skb_copy_datagram_const_iovec which is
> the worst of both worlds, plus it duplicates tons of code.
>
> So here's a few patches to kill this crap.
To pick one direction and go with it, I totally agree with.
But a patch set like this as an interim solution, I am not so happy
with.
If the method says const, we have a contract with the caller to not
modify the iovec. That caller can assume that we have not done so.
So this patch set violated that contract and can result in real bugs
either now or in the future.
I'll see if I can make some progress converting the networking over
to iov_iter. It can't be that difficult... albeit perhaps a little
time consuming.
^ 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