* Re: pull request: wireless 2014-09-05
From: David Miller @ 2014-09-07 23:11 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20140905150453.GB3454@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 5 Sep 2014 11:04:53 -0400
> Please pull this batch of fixes intended for the 3.17 stream...
>
> For the mac80211 bits, Johannes says:
>
> "Here are a few fixes for mac80211. One has been discussed for a while
> and adds a terminating NUL-byte to the alpha2 sent to userspace, which
> shouldn't be necessary but since many places treat it as a string we
> couldn't move to just sending two bytes.
>
> In addition to that, we have two VLAN fixes from Felix, a mesh fix, a
> fix for the recently introduced RX aggregation offload, a revert for
> a broken patch (that luckily didn't really cause any harm) and a small
> fix for alignment in debugfs."
>
> For the iwlwifi bits, Emmanuel says:
>
> "I revert a patch that disabled CTS to self in dvm because users
> reported issues. The revert is CCed to stable since the offending
> patch was sent to stable too. I also bump the firmware API versions
> since a new firmware is coming up. On top of that, Marcel fixes a
> bug I introduced while fixing a bug in our Kconfig file."
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH] net: phy: mdio-sun4i: don't select REGULATOR
From: David Miller @ 2014-09-07 23:12 UTC (permalink / raw)
To: b.galvani; +Cc: f.fainelli, maxime.ripard, arnd, netdev, linux-kernel
In-Reply-To: <1409956103-23473-1-git-send-email-b.galvani@gmail.com>
From: Beniamino Galvani <b.galvani@gmail.com>
Date: Sat, 6 Sep 2014 00:28:23 +0200
> The mdio-sun4i driver automatically selects REGULATOR and
> REGULATOR_FIXED_VOLTAGE because it uses the regulator API. But a
> driver selecting a subsystem increases the chance of generating
> circular Kconfig dependencies, especially when other drivers depend on
> the selected symbol.
>
> Since the regulator API functions are replaced with no-ops when
> REGULATOR is disabled, the driver can be built successfully even
> without regulator support and so those 'select' dependencies can be
> safely dropped.
>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: bpf: consolidate JIT binary allocator
From: David Miller @ 2014-09-07 23:15 UTC (permalink / raw)
To: dborkman; +Cc: ast, netdev, edumazet, heiko.carstens, schwidefsky
In-Reply-To: <1409996567-2170-2-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Sat, 6 Sep 2014 11:42:45 +0200
> While reviewing the code, I think on s390, the alignment masking
> seems not to be correct in it's current form, that is, we make sure
> the first instruction starts at an even address as stated by commit
> aa2d2c73c21f but masks the start with '& -2' while 2 byte-alignment
> should rather be '& ~1'.
Both -2 and ~1 are the same value.
^ permalink raw reply
* Re: [PATCH][net-next] openvswitch: change the data type of error status to atomic_long_t
From: David Miller @ 2014-09-07 23:17 UTC (permalink / raw)
To: roy.qing.li; +Cc: pshelar, netdev
In-Reply-To: <CAJFZqHwK=5iXxBP+SgcLtub=HSkTt9Pd6LU2_Tjn9qTxbQd3SA@mail.gmail.com>
From: Li RongQing <roy.qing.li@gmail.com>
Date: Sun, 7 Sep 2014 17:24:11 +0800
> 2. I did not find that tx_dropped/tx_error/.. is protected by spin
> lock under net dir,
> sometime tx_dropped is atomic_long_t; sometime it is percpu variable;
> sometime it is
> u64,but does not need to protect.
If it is only modified in ->ndo_start_xmit() then it is protected by
the per-queue TX lock, as ->ndo_start_xmit() is always invoked with
it held (except in LLTX drivers of course).
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] Re-check for a VIO_DESC_READY data descriptor after short udelay()
From: David Miller @ 2014-09-07 23:19 UTC (permalink / raw)
To: sowmini.varadhan; +Cc: david.stevens, netdev
In-Reply-To: <20140906210253.GA5710@oracle.com>
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Sat, 6 Sep 2014 17:02:53 -0400
> So what (if any) is the outstanding question about wmb() at this
> point?
I don't think there is any, thanks.
^ permalink raw reply
* Re: [PATCH net-next v4 2/3] net-timestamp: Make the clone operation stand-alone from phy timestamping
From: Alexander Duyck @ 2014-09-07 23:35 UTC (permalink / raw)
To: Richard Cochran, Alexander Duyck; +Cc: netdev, davem, willemb
In-Reply-To: <20140907215039.GA3900@localhost.localdomain>
On 09/07/2014 02:50 PM, Richard Cochran wrote:
> Just saw this now, was away on vacation, so sorry for the delay...
>
> On Thu, Sep 04, 2014 at 01:31:35PM -0400, Alexander Duyck wrote:
>> v2: Renamed function to skb_clone_sk.
>> Added destructor to call sock_put instead of doing it ourselves.
>> Dropped freeing functionality from skb_complete_tx_timestamp.
> ...
>
>> diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
>> index d5991ac..87648b3 100644
>> --- a/drivers/net/phy/dp83640.c
>> +++ b/drivers/net/phy/dp83640.c
>> @@ -1148,7 +1148,7 @@ static void dp83640_remove(struct phy_device *phydev)
>> kfree_skb(skb);
>>
>> while ((skb = skb_dequeue(&dp83640->tx_queue)) != NULL)
>> - skb_complete_tx_timestamp(skb, NULL);
>> + kfree_skb(skb);
> The way the code was before, there was a clear usage pattern for
> phy_driver.txtstamp() and skb_complete_tx_timestamp() which was also
> documented in the comment to the latter.
>
> Now, we have drivers freeing buffers allocated by the stack. I
> thought it was cleaner to have the same layer allocate and free the
> clone. Even if you say that this new way is just fine, still you
> should correct the comment to reflect the new pattern.
The "new" pattern is how we have done it for all Tx skbs handed down by
the stack, so why should we treat Tx timestamp SKBs any different? If
anything this change eliminates a risk since now they don't have to
remember specifically to use a special "destructor included" callback to
free the buffer and the socket. Instead all of the standard
kfree/consume_skb calls can be used to free the buffer.
It just occurred to me when I was looking at this code is that it can
now use standard calls such as __skb_queue_purge instead of having to
implement its own version of the call. I will try to remember to submit
a patch for that tomorrow.
Thanks,
Alex
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2014-09-07 23:41 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix skb leak in mac802154, from Martin Townsend.
2) Use select not depends on NF_NAT for NFT_NAT, from Pablo Neira Ayuso.
3) Fix union initializer bogosity in vxlan, from Gerhard Stenzel.
4) Fix RX checksum configuration in stmmac driver, from Giuseppe
CAVALLARO.
5) Fix TSO with non-accelerated VLANs in e1000, e1000e, bna, ehea, i40e,
i40evf, mvneta, and qlge, from Vlad Yasevich.
6) Fix capability checks in phy_init_eee(), from Giuseppe CAVALLARO.
7) Try high order allocations more sanely for SKBs, specifically if a high
order allocation fails, fall back directly to zero order pages rather than
iterating down one order at a time. From Eric Dumazet.
8) Fix a memory leak in openvswitch, from Li RongQing.
9) amd-xgbe initializes wrong spinlock, from Thomas Lendacky.
10) RTNL locking was busted in setsockopt for anycast and multicast, fix
from Sabrina Dubroca.
11) Fix peer address refcount leak in ipv6, from Nicolas Dichtel.
12) DocBook typo fixes, from Masanari Iida.
Please pull, thanks a lot!
The following changes since commit 451fd72219dd6f3355e2d036c598544c760ee532:
Merge tag 'pwm/for-3.17-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm (2014-08-22 14:50:21 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net master
for you to fetch changes up to 45ce829dd010668c3839a61b25843590eb4677dc:
Merge tag 'master-2014-09-04' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless (2014-09-07 16:11:10 -0700)
----------------------------------------------------------------
Alexander Aring (2):
ieee802154: 6lowpan_rtnl: fix correct errno value
ieee802154: 6lowpan: ensure of sending 1280 packets
Alexander Y. Fomichev (1):
net: prevent of emerging cross-namespace symlinks
Alexey Khoroshilov (1):
at76c50x-usb: fix use after free on failure path in at76_probe()
Andy King (1):
VMXNET3: Check for map error in vmxnet3_set_mc
Anish Bhatt (1):
cnic : Cleanup CONFIG_IPV6 & VLAN check
Bartlomiej Zolnierkiewicz (2):
net: sh_eth: fix driver dependencies
net: calxedaxgmac: fix driver dependencies
Bob Copeland (1):
mac80211: mesh_plink: handle confirm frames with new plid
Chen Gang (1):
drivers/net/fddi/skfp/h/skfbi.h: Remove useless PCI_BASE_2ND macros
Daniel Borkmann (2):
netfilter: x_tables: allow to use default cgroup match
net: sctp: fix ABI mismatch through sctp_assoc_to_state helper
Daniel Hellstrom (1):
greth: moved TX ring cleaning to NAPI rx poll func
David S. Miller (10):
Merge branch 'tso_fix'
mvneta: Add missing if_vlan.h include.
Merge branch 'mlx4-net'
Merge branch 'stmmac-eee'
Merge tag 'master-2014-08-25' of git://git.kernel.org/.../linville/wireless
Merge branch 'amd-xgbe-net'
Merge branch 'cxgb4'
Merge git://git.kernel.org/.../pablo/nf
Merge branch 'amd-xgbe-net'
Merge tag 'master-2014-09-04' of git://git.kernel.org/.../linville/wireless
Denton Gentry (1):
mac80211: fix start_seq_num in Rx reorder offload
Eliad Peller (1):
regulatory: add NUL to alpha2
Emmanuel Grumbach (2):
Revert "iwlwifi: dvm: don't enable CTS to self"
iwlwifi: bump firmware API version to 10 for 7000 and 8000
Eric Dumazet (1):
net: attempt a single high order allocation
Eugene Crosser (1):
qeth: don't query for info if hardware not ready.
Felix Fietkau (2):
mac80211: ignore AP_VLAN in ieee80211_recalc_chanctx_chantype
mac80211: fix smps mode check for AP_VLAN
Geert Uytterhoeven (1):
drivers: net: NET_XGENE should depend on HAS_DMA
Gerhard Stenzel (1):
vxlan: fix incorrect initializer in union vxlan_addr
Giuseppe CAVALLARO (11):
stmmac: fix rx checksum programming
stmmac: set ptp_clock to NULL while unregister
phy: fix EEE checks inside the phy_init_eee.
stmmac: prevent false carrier sense detection
stmmac: fix tipo on mmc crc error
stmmac: ptp: fix the reference clock
stmmac: fix dma api misuse
stmmac: never check EEE in case of a switch is attached
stmmac: fix PLS bit setting when EEE is active
stmmac: fix the rx csum feature
stmmac: only remove RXCSUM feature if no rx coe is available
Guillaume Nault (1):
l2tp: fix race while getting PMTU on PPP pseudo-wire
Hariprasad Shenai (6):
cxgb4: Fix for handling 1Gb/s SFP+ Transceiver Modules
cxgb4: Fixed the code to use correct length for part number
cxgb4: Fix T5 adapter accessing T4 adapter registers
cxgb4: Detect and display firmware reported errors
cxgb4: Avoid dumping Write-only registers in register dump
cxgb4: Issue mbox commands on correct mbox
Hauke Mehrtens (1):
bcma: add PCI ID for spromless BCM43217
Himangi Saraogi (1):
rtlwifi: btcoexist: adjust double test
Ivan Vecera (1):
tg3: prevent ifup/ifdown during PCI error recovery
Johan Hedberg (1):
Bluetooth: Fix hci_conn reference counting for auto-connections
Johannes Berg (2):
Revert "mac80211: disable uAPSD if all ACs are under ACM"
mac80211: fix agg_status debugfs file alignment
John W. Linville (3):
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth
Merge tag 'mac80211-for-john-2014-08-29' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'for-john' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Jonas Jensen (4):
net: moxa: clear DESC1 on ndo_start_xmit()
net: moxa: replace build_skb() with netdev_alloc_skb_ip_align() / memcpy()
net: moxa: synchronize DMA memory
net: moxa: continue loop on skb allocation failure
Julian Anastasov (2):
ipvs: properly declare tunnel encapsulation
ipvs: fix ipv6 hook registration for local replies
Larry Finger (1):
rtlwifi: rtl8192cu: Add new ID
Lendacky, Thomas (7):
amd-xgbe: Check for Tx hardware queue flushing support
amd-xgbe: Reported fifo size from hardware is not correct
amd-xgbe: Fix the xpcs mmd debugfs support
amd-xgbe: Use the Tx queue count for Tx flow control support
amd-xgbe: Fix initialization of the wrong spin lock
amd-xgbe: Treat certain counter registers as 64 bit
amd-xgbe: Enable interrupts for all management counters
Li RongQing (2):
openvswitch: fix a memory leak
openvswitch: distinguish between the dropped and consumed skb
Maks Naumov (1):
ath9k: fix wrong string size for strncmp in write_file_spec_scan_ctl()
Manish Chopra (1):
bnx2x: Configure device endianity on driver load and reset endianity on removal.
Marcel Holtmann (1):
iwlwifi: Remove module build requirement for Intel Wireless WiFi
Martin Townsend (3):
mac802154: fixed potential skb leak with mac802154_parse_frame_start
ieee802154: mac802154: handle the reserved dest mode by dropping the packet
ieee802154: 6lowpan: ensure MTU of 1280 for 6lowpan
Masanari Iida (1):
net: treewide: Fix typo found in DocBook/networking.xml
Michal Kubeček (1):
net: fix checksum features handling in netif_skb_features()
Mika Westerberg (1):
net: rfkill: gpio: Add more Broadcom bluetooth ACPI IDs
Neil Horman (1):
3c59x: avoid panic in boomerang_start_xmit when finding page address:
Nicolas Dichtel (2):
ipv6: fix a refcnt leak with peer addr
ipv6: use addrconf_get_prefix_route() to remove peer addr
Or Gerlitz (2):
net/mlx4: Move the tunnel steering helper function to mlx4_core
mlx4: Set user-space raw Ethernet QPs to properly handle VXLAN traffic
Pablo Neira (1):
netfilter: fix missing dependencies in NETFILTER_XT_TARGET_LOG
Pablo Neira Ayuso (4):
netfilter: move NAT Kconfig switches out of the iptables scope
netfilter: nf_tables: nat expression must select CONFIG_NF_NAT
netfilter: NETFILTER_XT_TARGET_LOG selects NF_LOG_*
netfilter: add explicit Kconfig for NETFILTER_XT_NAT
Roland Stigge (1):
net: lpc_eth: Fix crash on ip link up
Sabrina Dubroca (1):
ipv6: fix rtnl locking in setsockopt for anycast and multicast
Vlad Yasevich (8):
e1000e: Fix TSO with non-accelerated vlans
e1000: Fix TSO for non-accelerated vlan traffic
bna: Support TSO and partial checksum with non-accelerated vlans.
ehea: Fix TSO and hw checksums with non-accelerated vlan packets.
i40e: Fix TSO and hw checksums for non-accelerated vlan packets.
i40evf: Fix TSO and hw checksums for non-accelerated vlan packets.
mvneta: Fix TSO and checksum for non-acceleration vlan traffic
qlge: Fix TSO for non-accelerated vlan traffic
WANG Cong (1):
ipv6: restore the behavior of ipv6_sock_ac_drop()
Wei Liu (1):
xen-netback: move netif_napi_add before binding interrupt
Willem de Bruijn (1):
net-timestamp: only report sw timestamp if reporting bit is set
Yaniv Rosner (1):
bnx2x: Fix link problems for 1G SFP RJ45 module
Zhouyi Zhou (1):
netfilter: HAVE_JUMP_LABEL instead of CONFIG_JUMP_LABEL
nandini sharma (2):
stmmac: fix the EEE LPI Macro definitions.
stmmac: fix LPI TW timer value to 20.5us.
Álvaro Fernández Rojas (1):
ssb: add PCI ID 0x4351
Documentation/devicetree/bindings/net/stmmac.txt | 4 ++
drivers/bcma/host_pci.c | 1 +
drivers/infiniband/hw/mlx4/main.c | 30 +++++++++
drivers/infiniband/hw/mlx4/qp.c | 8 ++-
drivers/net/ethernet/3com/3c59x.c | 8 +--
drivers/net/ethernet/aeroflex/greth.c | 86 +++++++++++++-----------
drivers/net/ethernet/aeroflex/greth.h | 2 +-
drivers/net/ethernet/amd/xgbe/xgbe-debugfs.c | 8 +--
drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 209 +++++++++++++++++++++++++++++++++------------------------
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 +
drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c | 7 +-
drivers/net/ethernet/amd/xgbe/xgbe-main.c | 2 +-
drivers/net/ethernet/amd/xgbe/xgbe.h | 4 ++
drivers/net/ethernet/apm/xgene/Kconfig | 1 +
drivers/net/ethernet/broadcom/Kconfig | 2 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h | 7 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 74 +++++++++++---------
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.h | 5 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 57 +++++++++++-----
drivers/net/ethernet/broadcom/cnic.c | 4 +-
drivers/net/ethernet/broadcom/tg3.c | 16 +++++
drivers/net/ethernet/broadcom/tg3.h | 1 +
drivers/net/ethernet/brocade/bna/bnad.c | 7 +-
drivers/net/ethernet/calxeda/Kconfig | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 16 +++--
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 79 ++++++++++++++++++----
drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 2 +
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 4 ++
drivers/net/ethernet/ibm/ehea/ehea_main.c | 2 +-
drivers/net/ethernet/intel/e1000/e1000_main.c | 19 +++---
drivers/net/ethernet/intel/e1000e/netdev.c | 21 +++---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +-
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 2 +-
drivers/net/ethernet/marvell/mvneta.c | 8 ++-
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 31 +--------
drivers/net/ethernet/mellanox/mlx4/mcg.c | 38 +++++++++++
drivers/net/ethernet/moxa/moxart_ether.c | 34 +++++-----
drivers/net/ethernet/nxp/lpc_eth.c | 3 +
drivers/net/ethernet/qlogic/qlge/qlge_main.c | 5 +-
drivers/net/ethernet/renesas/Kconfig | 1 +
drivers/net/ethernet/stmicro/stmmac/chain_mode.c | 14 ++--
drivers/net/ethernet/stmicro/stmmac/common.h | 13 ++--
drivers/net/ethernet/stmicro/stmmac/dwmac1000.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 6 +-
drivers/net/ethernet/stmicro/stmmac/mmc.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/mmc_core.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 15 +++--
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 9 ++-
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 142 +++++++++++++++++++++++++++++----------
drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h | 2 -
drivers/net/fddi/skfp/h/skfbi.h | 5 --
drivers/net/phy/phy.c | 18 ++---
drivers/net/vmxnet3/vmxnet3_drv.c | 15 +++--
drivers/net/vmxnet3/vmxnet3_int.h | 4 +-
drivers/net/vxlan.c | 8 +--
drivers/net/wireless/at76c50x-usb.c | 3 +-
drivers/net/wireless/ath/ath9k/spectral.c | 2 +-
drivers/net/wireless/iwlwifi/Kconfig | 2 -
drivers/net/wireless/iwlwifi/dvm/rxon.c | 12 ++++
drivers/net/wireless/iwlwifi/iwl-7000.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-8000.c | 2 +-
drivers/net/wireless/rtlwifi/btcoexist/halbtcoutsrc.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 1 +
drivers/net/xen-netback/interface.c | 6 +-
drivers/s390/net/qeth_core.h | 1 +
drivers/s390/net/qeth_core_main.c | 16 ++++-
drivers/s390/net/qeth_l2_sys.c | 7 +-
drivers/ssb/b43_pci_bridge.c | 1 +
include/linux/mlx4/device.h | 3 +
include/linux/netdevice.h | 4 +-
include/linux/netfilter.h | 5 +-
include/net/bluetooth/hci_core.h | 2 +
include/net/netns/ieee802154_6lowpan.h | 1 -
include/net/regulatory.h | 2 +-
include/net/sctp/sctp.h | 13 ++++
include/net/sock.h | 4 +-
include/net/wimax.h | 2 +-
include/trace/events/irq.h | 4 +-
net/bluetooth/hci_conn.c | 8 +++
net/bluetooth/hci_core.c | 14 +++-
net/bluetooth/hci_event.c | 17 ++++-
net/core/datagram.c | 2 +-
net/core/dev.c | 77 +++++++++++++++++++--
net/core/gen_estimator.c | 2 +-
net/core/gen_stats.c | 2 +-
net/core/skbuff.c | 4 +-
net/core/sock.c | 34 +++++-----
net/ieee802154/6lowpan_rtnl.c | 4 +-
net/ieee802154/reassembly.c | 15 +----
net/ipv4/netfilter/Kconfig | 102 +++++++++++++++-------------
net/ipv4/netfilter/Makefile | 2 +-
net/ipv6/addrconf.c | 29 +++-----
net/ipv6/anycast.c | 10 +++
net/ipv6/mcast.c | 14 ++++
net/ipv6/netfilter/Kconfig | 28 +++++---
net/ipv6/netfilter/Makefile | 2 +-
net/l2tp/l2tp_ppp.c | 3 +-
net/mac80211/chan.c | 2 +
net/mac80211/debugfs_sta.c | 2 +-
net/mac80211/iface.c | 4 +-
net/mac80211/mesh_plink.c | 7 +-
net/mac80211/mlme.c | 3 +-
net/mac80211/sta_info.c | 7 +-
net/mac802154/wpan.c | 6 +-
net/netfilter/Kconfig | 14 +++-
net/netfilter/Makefile | 2 +-
net/netfilter/core.c | 6 +-
net/netfilter/ipvs/ip_vs_core.c | 2 +-
net/netfilter/ipvs/ip_vs_xmit.c | 20 ++++--
net/netfilter/xt_cgroup.c | 2 +-
net/openvswitch/datapath.c | 11 ++-
net/rfkill/rfkill-gpio.c | 1 +
net/sctp/socket.c | 2 +-
net/socket.c | 5 +-
116 files changed, 1082 insertions(+), 555 deletions(-)
^ permalink raw reply
* Re: [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload
From: Simon Horman @ 2014-09-08 0:02 UTC (permalink / raw)
To: Scott Feldman
Cc: Sergey Ryazanov, jasowang-H+wXaHxf7aLQT0dZR+AlfA, John Fastabend,
Neil.Jerram-QnUH15yq9NYqDJ6do+/SaQ, Eric Dumazet, Andy Gospodarek,
dev-yBygre7rU0TnMu66kgdUjQ, Felix Fietkau, Florian Fainelli,
ronye-VPRAkNaXOzVWk0Htik3J/w, Jeff Kirsher, ogerlitz,
Ben Hutchings, Lennert Buytenhek, Jiri Pirko, Roopa Prabhu,
Jamal Hadi Salim, Aviad Raveh,
nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w, Vlad Yasevich,
Neil Horman, netdev, Stephen Hemminger, dborkman,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, David Miller <dav
In-Reply-To: <E3C7797F-081E-484F-918E-937C705B43D6-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
On Fri, Sep 05, 2014 at 12:02:03AM -0700, Scott Feldman wrote:
>
> On Sep 4, 2014, at 9:08 PM, Simon Horman <simon.horman@netronome.com> wrote:
>
> > On Thu, Sep 04, 2014 at 09:30:45AM -0700, Scott Feldman wrote:
> >>
> >> On Sep 4, 2014, at 2:04 AM, Simon Horman <simon.horman@netronome.com> wrote:
> >>
> >>>
> >>>
> >>> [snip]
> >>>
> >>> In relation to ports and datapaths it seems to me that the API that
> >>> has been developed accommodates a model where a port may belong to a
> >>> switch device; that this topology is fixed before any API calls are made
> >>> and that all all ports belonging to the same switch belong to the same
> >>> datapath.
> >>>
> >>> This makes sense in the case of hardware that looks a lot like a switch.
> >>> But I think that other scenarios are possible. For example hardware that
> >>> is able to handle the same abstractions handled by the datapath: datapaths
> >>> may be created or destroyed; vports may be added and removed from datapaths.
> >>>
> >>> So one might have a piece of hardware that is configured with more than one
> >>> datapath configured and its different ports belong to it might be
> >>> associated with different data paths.
> >>
> >> I’ve tested multiple datapaths on one switch hardware with the current patch set and it works fine, without the need to push down any datapath id in the API. It works because a switch port can’t belong to more than one datapath. Datapaths can be created/destroyed and ports added/removed from datapaths dynamically and the right sw_flows are added/removed to program HW.
> >
> > And the flows added to a switch always match the in port? Thus
> > so a given flow is only ever for one in-port and thus one datapath?
>
> Correct, for the particular switch implementation we’re working with. If
> another implementation can’t match on in_port then it seems datapath_id
> may be needed to partition flows.
Thanks, I understand and agree.
> >>> Or we might have hardware that is able to offload a tunnel vport.
> >
> > I think tunnel vports is still an unsolved part of the larger puzzle.
>
> Agreed, TBD work to offload tunnel vports. Current implementation only looking at VLAN vports so far.
>
> >
> >>> In short I am thinking in terms of API callbacks to manipulate datapaths
> >>> and vports. Although I have not thought about it in detail I believe
> >>> that the current model you have implemented using such a scheme because
> >>> the scheme I am suggesting maps to that of the datapath and you have
> >>> implemented your model there.
>
>
> -scott
>
>
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: bpf: consolidate JIT binary allocator
From: Alexei Starovoitov @ 2014-09-08 0:17 UTC (permalink / raw)
To: David Miller
Cc: Daniel Borkmann, Network Development, Eric Dumazet,
Heiko Carstens, Martin Schwidefsky
In-Reply-To: <20140907.161543.2206530539028176158.davem@davemloft.net>
On Sun, Sep 7, 2014 at 4:15 PM, David Miller <davem@davemloft.net> wrote:
> From: Daniel Borkmann <dborkman@redhat.com>
> Date: Sat, 6 Sep 2014 11:42:45 +0200
>
>> While reviewing the code, I think on s390, the alignment masking
>> seems not to be correct in it's current form, that is, we make sure
>> the first instruction starts at an even address as stated by commit
>> aa2d2c73c21f but masks the start with '& -2' while 2 byte-alignment
>> should rather be '& ~1'.
>
> Both -2 and ~1 are the same value.
oops. you're right. commit log is incorrect.
The new code makes the logic more clear:
in s390:
- *image_ptr = &header->image[(prandom_u32() % hole) & -2];
+ header = bpf_jit_binary_alloc(size, &jit.start, 2, bpf_jit_fill_hole);
and in bpf/core.c:
+struct bpf_binary_header *
+bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,
+ unsigned int alignment,
+ bpf_jit_fill_hole_t bpf_fill_ill_insns)
+{
...
+ start = (prandom_u32() % hole) & ~(alignment - 1);
we'll fix the commit log and resubmit.
Thx
^ permalink raw reply
* Re: [PATCH net-next v1 2/2] bonding: Simplify the xmit function for modes that use xmit_hash
From: Mahesh Bandewar @ 2014-09-08 2:23 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, David Miller,
netdev, Eric Dumazet, Maciej Zenczykowski
In-Reply-To: <540C351F.9070800@redhat.com>
On Sun, Sep 7, 2014 at 3:36 AM, Nikolay Aleksandrov <nikolay@redhat.com> wrote:
> On 09/07/2014 07:33 AM, Mahesh Bandewar wrote:
>> On Sat, Sep 6, 2014 at 4:02 AM, Nikolay Aleksandrov <nikolay@redhat.com> wrote:
>>> On 09/06/2014 08:35 AM, Mahesh Bandewar wrote:
>>>> Earlier change to use usable slave array for TLB mode had an additional
>>>> performance advantage. So extending the same logic to all other modes
>>>> that use xmit-hash for slave selection (viz 802.3AD, and XOR modes).
>>>> Also consolidating this with the earlier TLB change.
>>>>
>>>> The main idea is to build the usable slaves array in the control path
>>>> and use that array for slave selection during xmit operation.
>>>>
>>>> Measured performance in a setup with a bond of 4x1G NICs with 200
>>>> instances of netperf for the modes involved (3ad, xor, tlb)
>>>> cmd: netperf -t TCP_RR -H <TargetHost> -l 60 -s 5
>>>>
>>>> Mode TPS-Before TPS-After
>>>>
>>>> 802.3ad : 468,694 493,101
>>>> TLB (lb=0): 392,583 392,965
>>>> XOR : 475,696 484,517
>>>>
>>>> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>>>> ---
>>>> v1:
>>>> (a) If bond_update_slave_arr() fails to allocate memory, it will overwrite
>>>> the slave that need to be removed.
>>>> (b) Freeing of array will assign NULL (to handle bond->down to bond->up
>>>> transition gracefully.
>>>> (c) Change from pr_debug() to pr_err() if bond_update_slave_arr() returns
>>>> failure.
>>>> (d) XOR: bond_update_slave_arr() will consider mii-mon, arp-mon cases and
>>>> will populate the array even if these parameters are not used.
>>>> (e) 3AD: Should handle the ad_agg_selection_logic correctly.
>>>>
> <<<<<snip>>>>>
>>>> static int bond_close(struct net_device *bond_dev)
>>>> {
>>>> struct bonding *bond = netdev_priv(bond_dev);
>>>> + struct bond_up_slave *arr;
>>>>
>>>> bond_work_cancel_all(bond);
>>>> bond->send_peer_notif = 0;
>>>> @@ -3156,6 +3184,12 @@ static int bond_close(struct net_device *bond_dev)
>>>> bond_alb_deinitialize(bond);
>>>> bond->recv_probe = NULL;
>>>>
>>>> + arr = rtnl_dereference(bond->slave_arr);
>>>> + if (arr) {
>>>> + kfree_rcu(arr, rcu);
>>>> + RCU_INIT_POINTER(bond->slave_arr, NULL);
>>>> + }
>>>> +
>>> ^^^^^^^^
>>> Why do this in the first place ? I mean I could easily release a slave
>>> while the bond is down and rebuild the slave_arr.
>>>
>> If you do bond down the slave array is free-ed here, but next time
>> when the bond up operation is performed, the slave array will be
>> rebuilt. In that code, the logic always dereferences the earlier array
>> and since it's non-NULL, this might end-up in double-free situation.
>> So to avoid that I'm assigning NULL after the free.
>>
>>> One more issue that I just saw is that you might be leaking memory as
>>> ndo_uninit() is called for a device after dev_close_many() so you'll free
>>> the array here, but bond_uninit() calls __bond_release_slave and will
>>> rebuild it.
>>>
>> Shouldn't __bond_release_slave() be called before closing the bond()?
>> I'll have to check the code, but if you are right, then this is not
>> the correct place for this free operation and probably the better
>> place would be the bond_ununit() in that case.
>>
>>>> return 0;
>>>> }
>>>>
>>>> @@ -3684,15 +3718,108 @@ static int bond_xmit_activebackup(struct sk_buff *skb, struct net_device *bond_d
>>>> return NETDEV_TX_OK;
>>>> }
>>>>
>>>> -/* In bond_xmit_xor() , we determine the output device by using a pre-
>>>> - * determined xmit_hash_policy(), If the selected device is not enabled,
>>>> - * find the next active slave.
>>>> +/* Build the usable slaves array in control path for modes that use xmit-hash
>>>> + * to determine the slave interface -
>>>> + * (a) BOND_MODE_8023AD
>>>> + * (b) BOND_MODE_XOR
>>>> + * (c) BOND_MODE_TLB && tlb_dynamic_lb == 0
>>>> */
>>>> -static int bond_xmit_xor(struct sk_buff *skb, struct net_device *bond_dev)
>>>> +int bond_update_slave_arr(struct bonding *bond, struct slave *skipslave)
>>>> {
>>>> - struct bonding *bond = netdev_priv(bond_dev);
>>>> + struct slave *slave;
>>>> + struct list_head *iter;
>>>> + struct bond_up_slave *new_arr, *old_arr;
>>>> + int slaves_in_agg;
>>>> + int agg_id = 0;
>>>> + int ret = 0;
>>>> +
>>>> + new_arr = kzalloc(offsetof(struct bond_up_slave, arr[bond->slave_cnt]),
>>>> + GFP_ATOMIC);
>>>> + if (!new_arr) {
>>>> + ret = -ENOMEM;
>>>> + goto out;
>>>> + }
>>>> + if (BOND_MODE(bond) == BOND_MODE_8023AD) {
>>>> + struct ad_info ad_info;
>>>>
>>>> - bond_xmit_slave_id(bond, skb, bond_xmit_hash(bond, skb) % bond->slave_cnt);
>>>> + if (bond_3ad_get_active_agg_info(bond, &ad_info)) {
>>>> + pr_debug("bond_3ad_get_active_agg_info failed\n");
>>>> + kfree_rcu(new_arr, rcu);
>>>> + ret = -EINVAL;
>>>> + goto out;
>>>> + }
>>>> + slaves_in_agg = ad_info.ports;
>>>> + agg_id = ad_info.aggregator_id;
>>>> + }
>>>> + bond_for_each_slave(bond, slave, iter) {
>>>> + if (BOND_MODE(bond) == BOND_MODE_8023AD) {
>>>> + struct aggregator *agg;
>>>> +
>>>> + agg = SLAVE_AD_INFO(slave)->port.aggregator;
>>>> + if (!agg || agg->aggregator_identifier != agg_id)
>>>> + continue;
>>>> + }
>>>> + if (!bond_slave_can_tx(slave))
>>>> + continue;
>>>> + if (skipslave == slave)
>>>> + continue;
>>>> + new_arr->arr[new_arr->count++] = slave;
>>>> + }
>>>> +
>>>> + old_arr = rcu_dereference_protected(bond->slave_arr,
>>>> + lockdep_rtnl_is_held() ||
>>>> + lockdep_is_held(&bond->lock) ||
>>>> + lockdep_is_held(&bond->curr_slave_lock));
>>>> + rcu_assign_pointer(bond->slave_arr, new_arr);
>>>> + if (old_arr)
>>>> + kfree_rcu(old_arr, rcu);
>>>> +
>>>> +out:
>>>> + if (ret != 0 && skipslave) {
>>>> + int idx;
>>>> +
>>>> + /* Rare situation where caller has asked to skip a specific
>>>> + * slave but allocation failed (most likely!). In this sitation
>>>> + * overwrite the skipslave entry in the array with the last
>>>> + * entry from the array to avoid a situation where the xmit
>>>> + * path may choose this to-be-skipped slave to send a packet
>>>> + * out.
>>>> + */
>>>> + rcu_read_lock();
>>> ^^^^^^^^^^^^^^
>>> RCU ?
>>>
>> Shouldn't the array manipulation (the overwrite operation) be
>> performed with rcu-lock? May be I'm wrong!
>>
> I don't see any additional protection you'd get with RCU here, and for a
> writer it's definitely useless.
>
I'm not expecting any writer protection here since all the paths are
covered with some or the other lock at this moment. Just though that
performing array manipulation in RCU context would be useful.
>>>> + old_arr = rcu_dereference_protected(bond->slave_arr,
>>>> + lockdep_is_held(&bond->lock));
>>> ^^^^^^^^
>>> Only bond->lock ? This doesn't make any sense.
>>>
>> The only possibility here is from the __bond_release_one() because of
>> the skipslave and that path uses bond->lock.
>>
> Ah, okay now it makes sense, but then you should probably add a comment
> about that peculiarity and also lockdep_rtnl_is_held().
>
Will do.
>>>> + for (idx = 0; idx < old_arr->count; idx++) {
>>>> + if (skipslave == old_arr->arr[idx]) {
>>>> + if (idx != old_arr->count - 1)
>>> You can drop the "if" and remove one level of indentation, if idx == count
>>> - 1, then it'll overwrite itself (i.e. nothing) but count will still go down.
>>> But I think there's a potential bigger problem here as in the case of
>>> failure count might drop down to 0 but some transmitter might be pass the
>>> check and at the modulus part and if count is re-fetched we might end up
>>> with a div by zero.
>>>
>> __bond_release_one() uses write_lock_bh(). Isn't that sufficient to
>> prevent a potential xmitter from getting into that mode?
>>
> No, the xmit code was converted to RCU some time ago and runs in parallel
> with these operations. I've actually hit this bug with bond->slave_cnt
> before. You should probably edit the xmit code that uses ->count and make
> sure to fetch it only once.
>
Will do.
>>
>>>> + old_arr->arr[idx] =
>>>> + old_arr->arr[old_arr->count-1];
>>>> + old_arr->count--;
>>>> + break;
>>>> + }
>>>> + }
>>>> + rcu_read_unlock();
>>>> + }
>>>> + return ret;
>>>> +}
>>>> +
>>>> +/* Use this Xmit function for 3AD as well as XOR modes. The current
>>>> + * usable slave array is formed in the control path. The xmit function
>>>> + * just calculates hash and sends the packet out.
>>>> + */
>>>> +int bond_3ad_xor_xmit(struct sk_buff *skb, struct net_device *dev)
>>>> +{
>>>> + struct bonding *bond = netdev_priv(dev);
>>>> + struct slave *slave;
>>>> + struct bond_up_slave *slaves;
>>>> +
>>>> + slaves = rcu_dereference(bond->slave_arr);
>>>> + if (slaves && slaves->count) {
>>>> + slave = slaves->arr[bond_xmit_hash(bond, skb) % slaves->count];
>>>> + bond_dev_queue_xmit(bond, skb, slave->dev);
>>>> + } else {
>>>> + dev_kfree_skb_any(skb);
>>>> + atomic_long_inc(&dev->tx_dropped);
>>>> + }
>>>>
>>>> return NETDEV_TX_OK;
>>>> }
>>>> @@ -3794,12 +3921,11 @@ static netdev_tx_t __bond_start_xmit(struct sk_buff *skb, struct net_device *dev
>>>> return bond_xmit_roundrobin(skb, dev);
>>>> case BOND_MODE_ACTIVEBACKUP:
>>>> return bond_xmit_activebackup(skb, dev);
>>>> + case BOND_MODE_8023AD:
>>>> case BOND_MODE_XOR:
>>>> - return bond_xmit_xor(skb, dev);
>>>> + return bond_3ad_xor_xmit(skb, dev);
>>>> case BOND_MODE_BROADCAST:
>>>> return bond_xmit_broadcast(skb, dev);
>>>> - case BOND_MODE_8023AD:
>>>> - return bond_3ad_xmit_xor(skb, dev);
>>>> case BOND_MODE_ALB:
>>>> return bond_alb_xmit(skb, dev);
>>>> case BOND_MODE_TLB:
>>>> diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
>>>> index aace510d08d1..4a6195c0de60 100644
>>>> --- a/drivers/net/bonding/bonding.h
>>>> +++ b/drivers/net/bonding/bonding.h
>>>> @@ -177,6 +177,12 @@ struct slave {
>>>> struct kobject kobj;
>>>> };
>>>>
>>>> +struct bond_up_slave {
>>>> + unsigned int count;
>>>> + struct rcu_head rcu;
>>>> + struct slave *arr[0];
>>>> +};
>>>> +
>>>> /*
>>>> * Link pseudo-state only used internally by monitors
>>>> */
>>>> @@ -196,6 +202,7 @@ struct bonding {
>>>> struct slave __rcu *curr_active_slave;
>>>> struct slave __rcu *current_arp_slave;
>>>> struct slave *primary_slave;
>>>> + struct bond_up_slave __rcu *slave_arr; /* Array of usable slaves */
>>>> bool force_primary;
>>>> s32 slave_cnt; /* never change this value outside the attach/detach wrappers */
>>>> int (*recv_probe)(const struct sk_buff *, struct bonding *,
>>>> @@ -527,6 +534,7 @@ const char *bond_slave_link_status(s8 link);
>>>> struct bond_vlan_tag *bond_verify_device_path(struct net_device *start_dev,
>>>> struct net_device *end_dev,
>>>> int level);
>>>> +int bond_update_slave_arr(struct bonding *bond, struct slave *skipslave);
>>>>
>>>> #ifdef CONFIG_PROC_FS
>>>> void bond_create_proc_entry(struct bonding *bond);
>>>>
>>>
>
^ permalink raw reply
* RE: [PATCH 1/4] net: stmmac: enhance to support multiple device instances
From: Kweh, Hock Leong @ 2014-09-08 3:10 UTC (permalink / raw)
To: 'David Miller'
Cc: 'peppe.cavallaro@st.com',
'netdev@vger.kernel.org',
'linux-kernel@vger.kernel.org', Ong, Boon Leong,
'Rayagond K'
In-Reply-To: <F54AEECA5E2B9541821D670476DAE19C2B6E74EE@PGSMSX102.gar.corp.intel.com>
> -----Original Message-----
> From: Kweh, Hock Leong
> Sent: Saturday, August 30, 2014 11:48 AM
> To: David Miller
> Cc: peppe.cavallaro@st.com; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; Ong, Boon Leong; Rayagond K
> Subject: RE: [PATCH 1/4] net: stmmac: enhance to support multiple device
> instances
>
> > From: David Miller [mailto:davem@davemloft.net]
> > Sent: Saturday, August 30, 2014 11:06 AM
> > > From: Kweh Hock Leong <hock.leong.kweh@intel.com>
> > >Date: Wed, 27 Aug 2014 18:32:26 +0800
> > >
> > > +static int instance_id = 1;
> >
> > Don't do this instance stuff. Instead pull in some identifier that
> > can come from elsewhere.
>
> Regarding this, I would like to open up a discussion here. This "instance_id"
> actually is used for registering the mdio bus as a bus id. The original code use
> "1" for the bus id. If the system plug in more than one stmmac pci cards, I
> believe there is conflict on the mdio bus registration. So introduce this static
> global variable is to increase the bus id starting from "1" base on how many
> stmmac pci cards being plugged in.
>
> So, to change the "instance_id" by using some identifier, the only thing come
> to my mind is pci_dev->devfn number. Is anyone have concern about using
> devfn number as an mdio bus id ?
Hi David and everyone,
Just gently ping to see if any concern about the above discussion that
removing the instance_id and use the PCI_DEVID number for the mdio bus
number registration as showed below:
-static void stmmac_default_data(void)
+static void stmmac_default_data(struct plat_stmmacenet_data *plat_dat,
+ struct pci_dev *pdev)
{
- plat_dat.bus_id = 1;
+ plat_dat->bus_id = PCI_DEVID(pdev->bus->number, pdev->devfn);
Looking forward to get inputs from you guys. I will send the 2nd version
by this Wed if no one have concern to this. Thanks.
Regards,
Wilson
^ permalink raw reply
* [PATCH net-next] ethernet: ti: remove unwanted THIS_MODULE macro
From: Varka Bhadram @ 2014-09-08 3:58 UTC (permalink / raw)
To: netdev; +Cc: davem, balbi, mugunthanvnm, linux, linux-kernel, Varka Bhadram
It removes the owner field updation of driver structure.
It will be automatically updated by module_platform_driver()
Signed-off-by: Varka Bhadram <varkab@cdac.in>
---
drivers/net/ethernet/ti/cpmac.c | 1 -
drivers/net/ethernet/ti/cpsw-phy-sel.c | 1 -
drivers/net/ethernet/ti/cpsw.c | 1 -
drivers/net/ethernet/ti/davinci_emac.c | 1 -
drivers/net/ethernet/ti/davinci_mdio.c | 1 -
5 files changed, 5 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpmac.c b/drivers/net/ethernet/ti/cpmac.c
index f9bcf7a..dd94300 100644
--- a/drivers/net/ethernet/ti/cpmac.c
+++ b/drivers/net/ethernet/ti/cpmac.c
@@ -1207,7 +1207,6 @@ static int cpmac_remove(struct platform_device *pdev)
static struct platform_driver cpmac_driver = {
.driver = {
.name = "cpmac",
- .owner = THIS_MODULE,
},
.probe = cpmac_probe,
.remove = cpmac_remove,
diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c b/drivers/net/ethernet/ti/cpsw-phy-sel.c
index aa8bf45..0ea7832 100644
--- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
+++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
@@ -211,7 +211,6 @@ static struct platform_driver cpsw_phy_sel_driver = {
.probe = cpsw_phy_sel_probe,
.driver = {
.name = "cpsw-phy-sel",
- .owner = THIS_MODULE,
.of_match_table = cpsw_phy_sel_id_table,
},
};
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 03b4099..6d20e24 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2359,7 +2359,6 @@ MODULE_DEVICE_TABLE(of, cpsw_of_mtable);
static struct platform_driver cpsw_driver = {
.driver = {
.name = "cpsw",
- .owner = THIS_MODULE,
.pm = &cpsw_pm_ops,
.of_match_table = cpsw_of_mtable,
},
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 35a139e..ea71251 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -2083,7 +2083,6 @@ MODULE_DEVICE_TABLE(of, davinci_emac_of_match);
static struct platform_driver davinci_emac_driver = {
.driver = {
.name = "davinci_emac",
- .owner = THIS_MODULE,
.pm = &davinci_emac_pm_ops,
.of_match_table = of_match_ptr(davinci_emac_of_match),
},
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 2791f6f..98655b4 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -481,7 +481,6 @@ MODULE_DEVICE_TABLE(of, davinci_mdio_of_mtable);
static struct platform_driver davinci_mdio_driver = {
.driver = {
.name = "davinci_mdio",
- .owner = THIS_MODULE,
.pm = &davinci_mdio_pm_ops,
.of_match_table = of_match_ptr(davinci_mdio_of_mtable),
},
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net] ipv6: refresh rt6i_genid in ip6_pol_route()
From: Eric Dumazet @ 2014-09-08 4:18 UTC (permalink / raw)
To: David Miller; +Cc: nicolas.dichtel, therbert, alexander.h.duyck, netdev
In-Reply-To: <20140907.155446.2293591154334558042.davem@davemloft.net>
On Sun, 2014-09-07 at 15:54 -0700, David Miller wrote:
> This might be broken.
>
> We are dealing here with persistent entries in the ipv6 routine trie.
>
> If you just bump the genid on the next person to look it up, other
> sockets and cached entities might not have validated the route yet,
> and now will falsely see the route as valid. We have to ensure that
> they too drop this route and perform a relookup.
I am confused, I thought it was the role of the cookie.
(Ie socket has to store its own cookie to be able to validate a route)
Before 6f3118b571b8 patch, how was this done anyway ?
If persistent routes cannot refresh the genid, then they are useless ?
^ permalink raw reply
* Re: [PATCH net] ipv6: refresh rt6i_genid in ip6_pol_route()
From: David Miller @ 2014-09-08 4:27 UTC (permalink / raw)
To: eric.dumazet; +Cc: nicolas.dichtel, therbert, alexander.h.duyck, netdev
In-Reply-To: <1410149905.11872.73.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 07 Sep 2014 21:18:25 -0700
> On Sun, 2014-09-07 at 15:54 -0700, David Miller wrote:
>
>> This might be broken.
>>
>> We are dealing here with persistent entries in the ipv6 routine trie.
>>
>> If you just bump the genid on the next person to look it up, other
>> sockets and cached entities might not have validated the route yet,
>> and now will falsely see the route as valid. We have to ensure that
>> they too drop this route and perform a relookup.
>
> I am confused, I thought it was the role of the cookie.
>
> (Ie socket has to store its own cookie to be able to validate a route)
>
> Before 6f3118b571b8 patch, how was this done anyway ?
>
> If persistent routes cannot refresh the genid, then they are useless ?
I just speak about the genid aspect.
I understand that cookie (via node->fn_sernum) invalidates the path
in the fib_trie, but the genid protects against other circumstances
(matching IPSEC rule, f.e.)
You have to make sure all other sockets did a full route lookup
(including IPSEC) before you can safely adjust the genid.
I could be wrong, recheck my analysis please :-)
^ permalink raw reply
* Re: [PATCH net-next v1 2/2] bonding: Simplify the xmit function for modes that use xmit_hash
From: Eric Dumazet @ 2014-09-08 4:41 UTC (permalink / raw)
To: Mahesh Bandewar
Cc: Nikolay Aleksandrov, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek, David Miller, netdev, Eric Dumazet,
Maciej Zenczykowski
In-Reply-To: <CAF2d9jhF-utP0pyZNObmr9j4V8Hyp4qsf-NdseDF9Ka=24x+eA@mail.gmail.com>
On Sun, 2014-09-07 at 19:23 -0700, Mahesh Bandewar wrote:
> >
> I'm not expecting any writer protection here since all the paths are
> covered with some or the other lock at this moment. Just though that
> performing array manipulation in RCU context would be useful.
It is not useful. It is confusing only.
If you think of RCU as a replacement for reader/writer lock, its obvious
that once you get the writer lock, there is no need to get the reader
lock.
Extract from Documentation/RCU/whatisRCU.txt :
Use rcu_read_lock() and rcu_read_unlock() to guard RCU
read-side critical sections.
Use some solid scheme (such as locks or semaphores) to
keep concurrent updates from interfering with each other.
^ permalink raw reply
* Re: [PATCH net] ipv6: refresh rt6i_genid in ip6_pol_route()
From: Eric Dumazet @ 2014-09-08 4:43 UTC (permalink / raw)
To: David Miller; +Cc: nicolas.dichtel, therbert, alexander.h.duyck, netdev
In-Reply-To: <20140907.212742.893555292268057160.davem@davemloft.net>
On Sun, 2014-09-07 at 21:27 -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Sun, 07 Sep 2014 21:18:25 -0700
>
> > On Sun, 2014-09-07 at 15:54 -0700, David Miller wrote:
> >
> >> This might be broken.
> >>
> >> We are dealing here with persistent entries in the ipv6 routine trie.
> >>
> >> If you just bump the genid on the next person to look it up, other
> >> sockets and cached entities might not have validated the route yet,
> >> and now will falsely see the route as valid. We have to ensure that
> >> they too drop this route and perform a relookup.
> >
> > I am confused, I thought it was the role of the cookie.
> >
> > (Ie socket has to store its own cookie to be able to validate a route)
> >
> > Before 6f3118b571b8 patch, how was this done anyway ?
> >
> > If persistent routes cannot refresh the genid, then they are useless ?
>
> I just speak about the genid aspect.
>
> I understand that cookie (via node->fn_sernum) invalidates the path
> in the fib_trie, but the genid protects against other circumstances
> (matching IPSEC rule, f.e.)
>
> You have to make sure all other sockets did a full route lookup
> (including IPSEC) before you can safely adjust the genid.
>
> I could be wrong, recheck my analysis please :-)
So this whole genid protection can not work, unless we make sure a
socket cannot share a route with another socket.
This means we have to clone all routes.
^ permalink raw reply
* Re: [PATCH net-next v1 2/2] bonding: Simplify the xmit function for modes that use xmit_hash
From: Mahesh Bandewar @ 2014-09-08 4:51 UTC (permalink / raw)
To: Eric Dumazet
Cc: Nikolay Aleksandrov, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek, David Miller, netdev, Eric Dumazet,
Maciej Zenczykowski
In-Reply-To: <1410151290.11872.80.camel@edumazet-glaptop2.roam.corp.google.com>
On Sun, Sep 7, 2014 at 9:41 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sun, 2014-09-07 at 19:23 -0700, Mahesh Bandewar wrote:
>> >
>> I'm not expecting any writer protection here since all the paths are
>> covered with some or the other lock at this moment. Just though that
>> performing array manipulation in RCU context would be useful.
>
>
> It is not useful. It is confusing only.
>
> If you think of RCU as a replacement for reader/writer lock, its obvious
> that once you get the writer lock, there is no need to get the reader
> lock.
>
As I had mentioned earlier, simultaneous writers are taken care. The
xmit is lockless and was thinking about how not to get the xmit into
the scenario where this array manipulation is partially done and that
partial value is used by the xmitter and result may not be desirable.
Hence thought that rcu-read-lock will protect the xmitter getting into
that state. I guess that was incorrect so I'll remove the
read-lock/unlock from the code. Thanks for the clarification Eric.
> Extract from Documentation/RCU/whatisRCU.txt :
>
> Use rcu_read_lock() and rcu_read_unlock() to guard RCU
> read-side critical sections.
>
> Use some solid scheme (such as locks or semaphores) to
> keep concurrent updates from interfering with each other.
>
>
>
^ permalink raw reply
* Re: [PATCH net] ipv6: refresh rt6i_genid in ip6_pol_route()
From: David Miller @ 2014-09-08 4:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: nicolas.dichtel, therbert, alexander.h.duyck, netdev
In-Reply-To: <1410151434.11872.82.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 07 Sep 2014 21:43:54 -0700
> On Sun, 2014-09-07 at 21:27 -0700, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Sun, 07 Sep 2014 21:18:25 -0700
>>
>> > On Sun, 2014-09-07 at 15:54 -0700, David Miller wrote:
>> >
>> >> This might be broken.
>> >>
>> >> We are dealing here with persistent entries in the ipv6 routine trie.
>> >>
>> >> If you just bump the genid on the next person to look it up, other
>> >> sockets and cached entities might not have validated the route yet,
>> >> and now will falsely see the route as valid. We have to ensure that
>> >> they too drop this route and perform a relookup.
>> >
>> > I am confused, I thought it was the role of the cookie.
>> >
>> > (Ie socket has to store its own cookie to be able to validate a route)
>> >
>> > Before 6f3118b571b8 patch, how was this done anyway ?
>> >
>> > If persistent routes cannot refresh the genid, then they are useless ?
>>
>> I just speak about the genid aspect.
>>
>> I understand that cookie (via node->fn_sernum) invalidates the path
>> in the fib_trie, but the genid protects against other circumstances
>> (matching IPSEC rule, f.e.)
>>
>> You have to make sure all other sockets did a full route lookup
>> (including IPSEC) before you can safely adjust the genid.
>>
>> I could be wrong, recheck my analysis please :-)
>
> So this whole genid protection can not work, unless we make sure a
> socket cannot share a route with another socket.
>
> This means we have to clone all routes.
I'm willing to revert the change in question if you think that's the
sanest way forward.
The bug fix for more obscure use cases (IPSEC) if pointless if it
breaks more common things (TCP input route caching).
^ permalink raw reply
* Re: [PATCH net] ipv6: refresh rt6i_genid in ip6_pol_route()
From: Eric Dumazet @ 2014-09-08 5:07 UTC (permalink / raw)
To: David Miller; +Cc: nicolas.dichtel, therbert, alexander.h.duyck, netdev
In-Reply-To: <20140907.215943.213418445039957641.davem@davemloft.net>
On Sun, 2014-09-07 at 21:59 -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Sun, 07 Sep 2014 21:43:54 -0700
>
> > On Sun, 2014-09-07 at 21:27 -0700, David Miller wrote:
> >> From: Eric Dumazet <eric.dumazet@gmail.com>
> >> Date: Sun, 07 Sep 2014 21:18:25 -0700
> >>
> >> > On Sun, 2014-09-07 at 15:54 -0700, David Miller wrote:
> >> >
> >> >> This might be broken.
> >> >>
> >> >> We are dealing here with persistent entries in the ipv6 routine trie.
> >> >>
> >> >> If you just bump the genid on the next person to look it up, other
> >> >> sockets and cached entities might not have validated the route yet,
> >> >> and now will falsely see the route as valid. We have to ensure that
> >> >> they too drop this route and perform a relookup.
> >> >
> >> > I am confused, I thought it was the role of the cookie.
> >> >
> >> > (Ie socket has to store its own cookie to be able to validate a route)
> >> >
> >> > Before 6f3118b571b8 patch, how was this done anyway ?
> >> >
> >> > If persistent routes cannot refresh the genid, then they are useless ?
> >>
> >> I just speak about the genid aspect.
> >>
> >> I understand that cookie (via node->fn_sernum) invalidates the path
> >> in the fib_trie, but the genid protects against other circumstances
> >> (matching IPSEC rule, f.e.)
> >>
> >> You have to make sure all other sockets did a full route lookup
> >> (including IPSEC) before you can safely adjust the genid.
> >>
> >> I could be wrong, recheck my analysis please :-)
> >
> > So this whole genid protection can not work, unless we make sure a
> > socket cannot share a route with another socket.
> >
> > This means we have to clone all routes.
>
> I'm willing to revert the change in question if you think that's the
> sanest way forward.
>
> The bug fix for more obscure use cases (IPSEC) if pointless if it
> breaks more common things (TCP input route caching).
Lets wait for Nicolas and/or Hannes input, they might have some ideas...
^ permalink raw reply
* Re: [PATCH v10 net-next 2/2] net: filter: split filter.h and expose eBPF to user space
From: Ingo Molnar @ 2014-09-08 5:23 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Pablo Neira Ayuso, David S. Miller, Linus Torvalds,
Andy Lutomirski, Steven Rostedt, Daniel Borkmann,
Hannes Frederic Sowa, Chema Gonzalez, Eric Dumazet,
Peter Zijlstra, H. Peter Anvin, Andrew Morton, Kees Cook,
Linux API, Network Development, LKML
In-Reply-To: <CAMEtUuxJLDu8AAsZQdtG781vwC8y60Ygdt4ji5tbeyTE8YbWbQ@mail.gmail.com>
* Alexei Starovoitov <ast@plumgrid.com> wrote:
> > I don't think the speed up of the llvm submission is a good
> > argument, this sounds to me similar to the "please apply this
> > patch that reserves this new netlink family in
> > include/linux/netlink.h, I promise this new subsystem will be
> > submitted soon though. Meanwhile this will speed up
> > submission of my userspace software to distributions for
> > packaging" argument.
>
> You're not correct here. I'm not saying 'I promise it will be
> submitted'. There _were_ already submitted. [...]
And this split-up smaller submissions was requested by David
Miller, the networking maintainer, so if Pablo wants another
submission format, he needs to take it up with David - we can't
do both at once obviously.
Thanks,
Ingo
^ permalink raw reply
* [PATCH net-next 0/5] net: Changes to GRO for encapsulation
From: Tom Herbert @ 2014-09-08 5:26 UTC (permalink / raw)
To: davem, netdev
This patch set has some fixes for encapsulation and GRO.
Tom Herbert (5):
net: Fix GRE RX to use skb_transport_header for GRE header offset
ipip: Add gro callbacks to ipip offload
sit: Add gro callbacks to sit offload
udp: Add try convert checksum is case of skb_steal_sock
net: Export inet_offloads and inet6_offloads
net/ipv4/af_inet.c | 2 ++
net/ipv4/gre_demux.c | 5 ++---
net/ipv4/protocol.c | 1 +
net/ipv4/udp.c | 4 ++++
net/ipv6/ip6_offload.c | 2 ++
net/ipv6/protocol.c | 1 +
6 files changed, 12 insertions(+), 3 deletions(-)
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply
* [PATCH net-next 1/5] net: Fix GRE RX to use skb_transport_header for GRE header offset
From: Tom Herbert @ 2014-09-08 5:26 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1410153989-23837-1-git-send-email-therbert@google.com>
GRE assumes that the GRE header is at skb_network_header +
ip_hrdlen(skb). It is more general to use skb_transport_header
and this allows the possbility of inserting additional header
between IP and GRE (which is what we will done in Generic UDP
Encapsulation for GRE).
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/ipv4/gre_demux.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/gre_demux.c b/net/ipv4/gre_demux.c
index 7e0756d..4a7b5b2 100644
--- a/net/ipv4/gre_demux.c
+++ b/net/ipv4/gre_demux.c
@@ -98,7 +98,6 @@ EXPORT_SYMBOL_GPL(gre_build_header);
static int parse_gre_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
bool *csum_err)
{
- unsigned int ip_hlen = ip_hdrlen(skb);
const struct gre_base_hdr *greh;
__be32 *options;
int hdr_len;
@@ -106,7 +105,7 @@ static int parse_gre_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
if (unlikely(!pskb_may_pull(skb, sizeof(struct gre_base_hdr))))
return -EINVAL;
- greh = (struct gre_base_hdr *)(skb_network_header(skb) + ip_hlen);
+ greh = (struct gre_base_hdr *)skb_transport_header(skb);
if (unlikely(greh->flags & (GRE_VERSION | GRE_ROUTING)))
return -EINVAL;
@@ -116,7 +115,7 @@ static int parse_gre_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
if (!pskb_may_pull(skb, hdr_len))
return -EINVAL;
- greh = (struct gre_base_hdr *)(skb_network_header(skb) + ip_hlen);
+ greh = (struct gre_base_hdr *)skb_transport_header(skb);
tpi->proto = greh->protocol;
options = (__be32 *)(greh + 1);
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 2/5] ipip: Add gro callbacks to ipip offload
From: Tom Herbert @ 2014-09-08 5:26 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1410153989-23837-1-git-send-email-therbert@google.com>
Add inet_gro_receive and inet_gro_complete to ipip_offload to
support GRO.
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/ipv4/af_inet.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index d156b3c..6d6348d 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1670,6 +1670,8 @@ static const struct net_offload ipip_offload = {
.callbacks = {
.gso_send_check = inet_gso_send_check,
.gso_segment = inet_gso_segment,
+ .gro_receive = inet_gro_receive,
+ .gro_complete = inet_gro_complete,
},
};
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 3/5] sit: Add gro callbacks to sit offload
From: Tom Herbert @ 2014-09-08 5:26 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1410153989-23837-1-git-send-email-therbert@google.com>
Add ip6_gro_receive and inet_gro_complete to ip6_offload to
support GRO.
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/ipv6/ip6_offload.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index 5bcda33..12a686f 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -314,6 +314,8 @@ static const struct net_offload sit_offload = {
.callbacks = {
.gso_send_check = ipv6_gso_send_check,
.gso_segment = ipv6_gso_segment,
+ .gro_receive = ipv6_gro_receive,
+ .gro_complete = ipv6_gro_complete,
},
};
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 4/5] udp: Add try convert checksum is case of skb_steal_sock
From: Tom Herbert @ 2014-09-08 5:26 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1410153989-23837-1-git-send-email-therbert@google.com>
If an skb already has an associated socket that we can steal
in UDP receive then attempt checksum conversion before calling
udp_queue_rcv_skb.
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/ipv4/udp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index cd0db54..50d3b5c 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1769,6 +1769,10 @@ int __udp4_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
if (unlikely(sk->sk_rx_dst != dst))
udp_sk_rx_dst_set(sk, dst);
+ if (udp_sk(sk)->convert_csum && uh->check && !IS_UDPLITE(sk))
+ skb_checksum_try_convert(skb, IPPROTO_UDP, uh->check,
+ inet_compute_pseudo);
+
ret = udp_queue_rcv_skb(sk, skb);
sock_put(sk);
/* a return value > 0 means to resubmit the input, but
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
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