net: Eliminate no_check from protosw

It doesn't seem like an protocols are setting anything other
than the default, and allowing to arbitrarily disable checksums
for a whole protocol seems dangerous

net: Eliminate no_check from protosw

It doesn't seem like an protocols are setting anything other
than the default, and allowing to arbitrarily disable checksums
for a whole protocol seems dangerous. This can be done on a per
socket basis.

Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

show more ...

Merge commit 'v3.14' into next

Merge tag 'v3.14' into next

Linux 3.14

Merge tag 'v3.13' into next

Linux 3.13

Minor fixup needed in selinux_inet_conn_request()

Conflicts:
security/selinux/hooks.c

Merge branch 'next' into for-linus

First round of input updates for 3.15.

Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next

Conflicts:
drivers/gpu/drm/i915/Makefile

Makefile cleanup in drm-intel-next conflicts with a build-fix to move
intel_opregion un

Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next

Conflicts:
drivers/gpu/drm/i915/Makefile

Makefile cleanup in drm-intel-next conflicts with a build-fix to move
intel_opregion under CONFIG_ACPI.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

show more ...

Merge tag 'v3.14-rc6' into drm-intel-next-queued

Linux 3.14-rc6

I need the hdmi/dvi-dual link fixes in 3.14 to avoid ugly conflicts
when merging Ville's new hdmi cloning support into my -next tree

Merge tag 'v3.14-rc6' into drm-intel-next-queued

Linux 3.14-rc6

I need the hdmi/dvi-dual link fixes in 3.14 to avoid ugly conflicts
when merging Ville's new hdmi cloning support into my -next tree

Conflicts:
drivers/gpu/drm/i915/Makefile
drivers/gpu/drm/i915/intel_dp.c

Makefile cleanup conflicts with an acpi build fix, intel_dp.c is
trivial.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

show more ...

Merge tag 'v3.13' into for-3.15

Linux 3.13

Conflicts:
include/net/xfrm.h

Simple merge where v3.13 removed 'extern' from definitions and the audit
tree did s/u32/unsigned int/ to the same definiti

Merge tag 'v3.13' into for-3.15

Linux 3.13

Conflicts:
include/net/xfrm.h

Simple merge where v3.13 removed 'extern' from definitions and the audit
tree did s/u32/unsigned int/ to the same definitions.

show more ...

Merge tag 'parse-val' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap into asoc-core

regmap: Add parse_val() API

This is useful for generic code built on top of regmap dealing with

Merge tag 'parse-val' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap into asoc-core

regmap: Add parse_val() API

This is useful for generic code built on top of regmap dealing with
blocks of data.

show more ...

Merge tag 'v3.14-rc4' into next

Merge with Linux 3.14-rc4 to bring devm_request_any_context_irq().

Merge tag 'xtensa-for-next-20140221-1' into for_next

Xtensa fixes for 3.14:
- allow booting xtfpga on boards with new uBoot and >128MBytes memory;
- drop nonexistent GPIO32 support from fsf variant;

Merge tag 'xtensa-for-next-20140221-1' into for_next

Xtensa fixes for 3.14:
- allow booting xtfpga on boards with new uBoot and >128MBytes memory;
- drop nonexistent GPIO32 support from fsf variant;
- don't select USE_GENERIC_SMP_HELPERS;
- enable common clock framework support, set up ethoc clock on xtfpga;
- wire up sched_setattr and sched_getattr syscalls.

Signed-off-by: Chris Zankel <chris@zankel.net>

show more ...

Merge branch 'master' into for-next

Merge branch 'linus' into perf/core

Refresh the branch to a v3.14-rc base before queueing up new devel patches.

Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge tag 'efi-urgent' into x86/urgent

* Avoid WARN_ON() when mapping BGRT on Baytrail (EFI 32-bit).

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

Merge tag 'v3.13' into stable-3.14

Linux 3.13

Conflicts:
security/selinux/hooks.c

Trivial merge issue in selinux_inet_conn_request() likely due to me
including patches that I sent to the stable f

Merge tag 'v3.13' into stable-3.14

Linux 3.13

Conflicts:
security/selinux/hooks.c

Trivial merge issue in selinux_inet_conn_request() likely due to me
including patches that I sent to the stable folks in my next tree
resulting in the patch hitting twice (I think). Thankfully it was an
easy fix this time, but regardless, lesson learned, I will not do that
again.

show more ...

Merge remote-tracking branch 'wireless-next/master' into ath-next

Merge tag 'v3.14-rc1' into patchwork

Linus 3.14-rc1

* tag 'v3.14-rc1': (11781 commits)
Linus 3.14-rc1
hpfs: optimize quad buffer loading
hpfs: remember free space
parisc: add flexible mmap

Merge tag 'v3.14-rc1' into patchwork

Linus 3.14-rc1

* tag 'v3.14-rc1': (11781 commits)
Linus 3.14-rc1
hpfs: optimize quad buffer loading
hpfs: remember free space
parisc: add flexible mmap memory layout support
parisc: Make EWOULDBLOCK be equal to EAGAIN on parisc
parisc: convert uapi/asm/stat.h to use native types only
parisc: wire up sched_setattr and sched_getattr
parisc: fix cache-flushing
parisc/sti_console: prefer Linux fonts over built-in ROM fonts
hwmon: Fix SENSORS_TMP102 dependencies to eliminate build errors
hwmon: Fix SENSORS_LM75 dependencies to eliminate build errors
tools/power turbostat: introduce -s to dump counters
tools/power turbostat: remove unused command line option
afs: proc cells and rootcell are writeable
tile: remove compat_sys_lookup_dcookie declaration to fix compile error
Revert "PCI: Remove from bus_list and release resources in pci_release_dev()"
ARM: multi_v7_defconfig: remove redundant entries and re-enable TI_EDMA
ARM: multi_v7_defconfig: add mvebu drivers
clocksource: kona: Add basic use of external clock
drivers: bus: fix CCI driver kcalloc call parameters swap
...

show more ...

Merge branch 'linus' into sched/core, to resolve conflicts

Conflicts:
kernel/sysctl.c

Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge branch 'linus' into core/locking

Refresh the topic.

Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge branch 'master' into staging-next

We need the network changes in staging-next in order to be able to fix
up the rtl8821ae driver to build properly.

Signed-off-by: Greg Kroah-Hartman <gregkh@l

Merge branch 'master' into staging-next

We need the network changes in staging-next in order to be able to fix
up the rtl8821ae driver to build properly.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next

Pull networking updates from David Miller:

1) BPF debugger and asm tool by Daniel Borkmann.

2) Speed up create/bind in AF_PACKE

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next

Pull networking updates from David Miller:

1) BPF debugger and asm tool by Daniel Borkmann.

2) Speed up create/bind in AF_PACKET, also from Daniel Borkmann.

3) Correct reciprocal_divide and update users, from Hannes Frederic
Sowa and Daniel Borkmann.

4) Currently we only have a "set" operation for the hw timestamp socket
ioctl, add a "get" operation to match. From Ben Hutchings.

5) Add better trace events for debugging driver datapath problems, also
from Ben Hutchings.

6) Implement auto corking in TCP, from Eric Dumazet. Basically, if we
have a small send and a previous packet is already in the qdisc or
device queue, defer until TX completion or we get more data.

7) Allow userspace to manage ipv6 temporary addresses, from Jiri Pirko.

8) Add a qdisc bypass option for AF_PACKET sockets, from Daniel
Borkmann.

9) Share IP header compression code between Bluetooth and IEEE802154
layers, from Jukka Rissanen.

10) Fix ipv6 router reachability probing, from Jiri Benc.

11) Allow packets to be captured on macvtap devices, from Vlad Yasevich.

12) Support tunneling in GRO layer, from Jerry Chu.

13) Allow bonding to be configured fully using netlink, from Scott
Feldman.

14) Allow AF_PACKET users to obtain the VLAN TPID, just like they can
already get the TCI. From Atzm Watanabe.

15) New "Heavy Hitter" qdisc, from Terry Lam.

16) Significantly improve the IPSEC support in pktgen, from Fan Du.

17) Allow ipv4 tunnels to cache routes, just like sockets. From Tom
Herbert.

18) Add Proportional Integral Enhanced packet scheduler, from Vijay
Subramanian.

19) Allow openvswitch to mmap'd netlink, from Thomas Graf.

20) Key TCP metrics blobs also by source address, not just destination
address. From Christoph Paasch.

21) Support 10G in generic phylib. From Andy Fleming.

22) Try to short-circuit GRO flow compares using device provided RX
hash, if provided. From Tom Herbert.

The wireless and netfilter folks have been busy little bees too.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (2064 commits)
net/cxgb4: Fix referencing freed adapter
ipv6: reallocate addrconf router for ipv6 address when lo device up
fib_frontend: fix possible NULL pointer dereference
rtnetlink: remove IFLA_BOND_SLAVE definition
rtnetlink: remove check for fill_slave_info in rtnl_have_link_slave_info
qlcnic: update version to 5.3.55
qlcnic: Enhance logic to calculate msix vectors.
qlcnic: Refactor interrupt coalescing code for all adapters.
qlcnic: Update poll controller code path
qlcnic: Interrupt code cleanup
qlcnic: Enhance Tx timeout debugging.
qlcnic: Use bool for rx_mac_learn.
bonding: fix u64 division
rtnetlink: add missing IFLA_BOND_AD_INFO_UNSPEC
sfc: Use the correct maximum TX DMA ring size for SFC9100
Add Shradha Shah as the sfc driver maintainer.
net/vxlan: Share RX skb de-marking and checksum checks with ovs
tulip: cleanup by using ARRAY_SIZE()
ip_tunnel: clear IPCB in ip_tunnel_xmit() in case dst_link_failure() is called
net/cxgb4: Don't retrieve stats during recovery
...

show more ...

Merge branch 'gro_udp_encap'

Or Gerlitz says:

====================
net: Add GRO support for UDP encapsulating protocols

This series adds GRO handlers for protocols that do UDP encapsulation, with

Merge branch 'gro_udp_encap'

Or Gerlitz says:

====================
net: Add GRO support for UDP encapsulating protocols

This series adds GRO handlers for protocols that do UDP encapsulation, with the
intent of being able to coalesce packets which encapsulate packets belonging to
the same TCP session.

For GRO purposes, the destination UDP port takes the role of the ether type
field in the ethernet header or the next protocol in the IP header.

The UDP GRO handler will only attempt to coalesce packets whose destination
port is registered to have gro handler.

The patches done against net-next 75e4364f67 "net: stmmac: fix NULL pointer
dereference in stmmac_get_tx_hwtstamp"

Or.

v4 --> v5 changes:
- followed Eric's directives to avoid using atomic get/put ops on the
udp gro receive and complete callbacks and instead keep the rcu_read_lock
when calling the next handler on the chain.

v3 --> v4 changes:

- applied feedback from Tom on some micro-optimizations that save
branches and goto directives in the udp gro logic

- applied feedback from Eric on correct RCU programming for the
add/remove flow of the upper protocols udp gro handlers

v2 --> v3 changes:

- moved to use linked list to store the udp gro handlers, this solves the
problem of consuming 512KB of memory for the handlers.

- use a mark on the skb GRO CB data to disallow running the udp gro_receive twice
on a packet, this solves the problem of udp encapsulated packets whose inner VM
packet is udp and happen to carry a port which has registered offloads - and flush it.

- invoke the udp offload protocol registration and de-registration from the vxlan driver
in a sleepable context
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

show more ...

net: Add GRO support for UDP encapsulating protocols

Add GRO handlers for protocols that do UDP encapsulation, with the intent of
being able to coalesce packets which encapsulate packets belonging t

net: Add GRO support for UDP encapsulating protocols

Add GRO handlers for protocols that do UDP encapsulation, with the intent of
being able to coalesce packets which encapsulate packets belonging to
the same TCP session.

For GRO purposes, the destination UDP port takes the role of the ether type
field in the ethernet header or the next protocol in the IP header.

The UDP GRO handler will only attempt to coalesce packets whose destination
port is registered to have gro handler.

Use a mark on the skb GRO CB data to disallow (flush) running the udp gro receive
code twice on a packet. This solves the problem of udp encapsulated packets whose
inner VM packet is udp and happen to carry a port which has registered offloads.

Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

show more ...

Merge branch 'ip_forward_pmtu'

Hannes Frederic Sowa says:

====================
path mtu hardening patches

After a lot of back and forth I want to propose these changes regarding
path mtu hardening

Merge branch 'ip_forward_pmtu'

Hannes Frederic Sowa says:

====================
path mtu hardening patches

After a lot of back and forth I want to propose these changes regarding
path mtu hardening and give an outline why I think this is the best way
how to proceed:

This set contains the following patches:
* ipv4: introduce ip_dst_mtu_maybe_forward and protect forwarding path against pmtu spoofing
* ipv6: introduce ip6_dst_mtu_forward and protect forwarding path with it
* ipv4: introduce hardened ip_no_pmtu_disc mode

The first one switches the forwarding path of IPv4 to use the interface
mtu by default and ignore a possible discovered path mtu. It provides
a sysctl to switch back to the original behavior (see discussion below).

The second patch does the same thing unconditionally for IPv6. I don't
provide a knob for IPv6 to switch to original behavior (please see
below).

The third patch introduces a hardened pmtu mode, where only pmtu
information are accepted where the protocol is able to do more stringent
checks on the icmp piggyback payload (please see the patch commit msg
for further details).

Why is this change necessary?

First of all, RFC 1191 4. Router specification says:
"When a router is unable to forward a datagram because it exceeds the
MTU of the next-hop network and its Don't Fragment bit is set, the
router is required to return an ICMP Destination Unreachable message
to the source of the datagram, with the Code indicating
"fragmentation needed and DF set". ..."

For some time now fragmentation has been considered problematic, e.g.:
* http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf
* http://tools.ietf.org/search/rfc4963

Most of them seem to agree that fragmentation should be avoided because
of efficiency, data corruption or security concerns.

Recently it was shown possible that correctly guessing IP ids could lead
to data injection on DNS packets:
<https://sites.google.com/site/hayashulman/files/fragmentation-poisoning.pdf>

While we can try to completly stop fragmentation on the end host
(this is e.g. implemented via IP_PMTUDISC_INTERFACE), we cannot stop
fragmentation completly on the forwarding path. On the end host the
application has to deal with MTUs and has to choose fallback methods
if fragmentation could be an attack vector. This is already the case for
most DNS software, where a maximum UDP packet size can be configured. But
until recently they had no control over local fragmentation and could
thus emit fragmented packets.

On the forwarding path we can just try to delay the fragmentation to
the last hop where this is really necessary. Current kernel already does
that but only because routers don't receive feedback of path mtus, these are
only send back to the end host system. But it is possible to maliciously
insert path mtu inforamtion via ICMP packets which have an icmp echo_reply
payload, because we cannot validate those notifications against local
sockets. DHCP clients which establish an any-bound RAW-socket could also
start processing unwanted fragmentation-needed packets.

Why does IPv4 has a knob to revert to old behavior while IPv6 doesn't?

IPv4 does fragmentation on the path while IPv6 does always respond with
packet-too-big errors. The interface MTU will always be greater than
the path MTU information. So we would discard packets we could actually
forward because of malicious information. After this change we would
let the hop, which really could not forward the packet, notify the host
of this problem.

IPv4 allowes fragmentation mid-path. In case someone does use a software
which tries to discover such paths and assumes that the kernel is handling
the discovered pmtu information automatically. This should be an extremly
rare case, but because I could not exclude the possibility this knob is
provided. Also this software could insert non-locked mtu information
into the kernel. We cannot distinguish that from path mtu information
currently. Premature fragmentation could solve some problems in wrongly
configured networks, thus this switch is provided.

One frag-needed packet could reduce the path mtu down to 522 bytes
(route/min_pmtu).

Misc:

IPv6 neighbor discovery could advertise mtu information for an
interface. These information update the ipv6-specific interface mtu and
thus get used by the forwarding path.

Tunnel and xfrm output path will still honour path mtu and also respond
with Packet-too-Big or fragmentation-needed errors if needed.

Changelog for all patches:
v2)
* enabled ip_forward_use_pmtu by default
* reworded
v3)
* disabled ip_forward_use_pmtu by default
* reworded
v4)
* renamed ip_dst_mtu_secure to ip_dst_mtu_maybe_forward
* updated changelog accordingly
* removed unneeded !!(... & ...) double negations

v2)
* by default we honour pmtu information
3)
* only honor interface mtu
* rewritten and simplified
* no knob to fall back to old mode any more

v2)
* reworded Documentation
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

show more ...

ipv4: introduce hardened ip_no_pmtu_disc mode

This new ip_no_pmtu_disc mode only allowes fragmentation-needed errors
to be honored by protocols which do more stringent validation on the
ICMP's packe

ipv4: introduce hardened ip_no_pmtu_disc mode

This new ip_no_pmtu_disc mode only allowes fragmentation-needed errors
to be honored by protocols which do more stringent validation on the
ICMP's packet payload. This knob is useful for people who e.g. want to
run an unmodified DNS server in a namespace where they need to use pmtu
for TCP connections (as they are used for zone transfers or fallback
for requests) but don't want to use possibly spoofed UDP pmtu information.

Currently the whitelisted protocols are TCP, SCTP and DCCP as they check
if the returned packet is in the window or if the association is valid.

Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>
Cc: John Heffner <johnwheffner@gmail.com>
Suggested-by: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

show more ...