- 02 May, 2016 2 commits
-
-
Michal Schmidt authored
An out of bounds read of 2 bytes was discovered in cxgb3 with KASAN. t3_config_rss() expects both arrays it gets as parameters to have terminators. setup_rss(), the caller, forgets to add a terminator to one of the arrays. Thankfully the iteration in t3_config_rss() stops anyway, but in the last iteration the check for the terminator is an out of bounds read. Add the missing terminator to rspq_map[]. Reported-by:
Jan Stancek <jstancek@redhat.com> Signed-off-by:
Michal Schmidt <mschmidt@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arnd Bergmann authored
This takes the MAC address for smsc75xx/smsc95xx USB network devices from a the device tree. This is required to get a usable persistent address on the popular beagleboard, whose hardware designers accidentally forgot that an ethernet device really requires an a MAC address to be functional. The Raspberry Pi also ships smsc9514 without a serial EEPROM, stores the MAC address in ROM accessible via VC4 firmware. The smsc75xx and smsc95xx drivers are just two copies of the same code, so better fix both. [lkundrak@v3.sk: updated to use of_get_property() as per suggestion from Arnd, reworded the message and comments a bit] Tested-by:
Lubomir Rintel <lkundrak@v3.sk> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
- 01 May, 2016 2 commits
-
-
Craig Gallek authored
I forgot to include a check for listener port equality when deciding if two sockets should belong to the same reuseport group. This was not caught previously because it's only necessary when two listening sockets for the same user happen to hash to the same listener bucket. The same error does not exist in the UDP path. Fixes: c125e80b("soreuseport: fast reuseport TCP socket selection") Signed-off-by:
Craig Gallek <kraig@google.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Wang Shanker authored
This patch fixes a bug which causes the behavior of whether to ignore udp6 checksum of udp6 encapsulated l2tp tunnel contrary to what userspace program requests. When the flag `L2TP_ATTR_UDP_ZERO_CSUM6_RX` is set by userspace, it is expected that udp6 checksums of received packets of the l2tp tunnel to create should be ignored. In `l2tp_netlink.c`: `l2tp_nl_cmd_tunnel_create()`, `cfg.udp6_zero_rx_checksums` is set according to the flag, and then passed to `l2tp_core.c`: `l2tp_tunnel_create()` and then `l2tp_tunnel_sock_create()`. In `l2tp_tunnel_sock_create()`, `udp_conf.use_udp6_rx_checksums` is set the same to `cfg.udp6_zero_rx_checksums`. However, if we want the checksum to be ignored, `udp_conf.use_udp6_rx_checksums` should be set to `false`, i.e. be set to the contrary. Similarly, the same should be done to `udp_conf.use_udp6_tx_checksums`. Signed-off-by:
Miao Wang <shankerwangmiao@gmail.com> Acked-by:
James Chapman <jchapman@katalix.com> Signed-off-by:
-
- 29 Apr, 2016 1 commit
-
-
Paolo Abeni authored
After the commit e09acddf ("ip_tunnel: replace dst_cache with generic implementation"), a preemption debug warning is triggered on ip4 tunnels updating; the dst cache helper needs to be invoked in unpreemptible context. We don't need to load the cache on tunnel update, so this commit fixes the warning replacing the load with a dst cache reset, which is preempt safe. Fixes: e09acddf ("ip_tunnel: replace dst_cache with generic implementation") Reported-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Acked-by:
-
- 28 Apr, 2016 32 commits
-
-
David S. Miller authored
Alexei Starovoitov says: ==================== bpf: fix several bugs First two patches address bugs found by Jann Horn. Last patch is a minor samples fix spotted during the testing. ==================== Signed-off-by: -
Alexei Starovoitov authored
llvm cannot always recognize memset as builtin function and optimize it away, so just delete it. It was a leftover from testing of bpf_perf_event_output() with large data structures. Fixes: 39111695 ("samples: bpf: add bpf_perf_event_output example") Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Alexei Starovoitov authored
The commit 35578d79 ("bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter") introduced clever way to check bpf_helper<->map_type compatibility. Later on commit a43eec30 ("bpf: introduce bpf_perf_event_output() helper") adjusted the logic and inadvertently broke it. Get rid of the clever bool compare and go back to two-way check from map and from helper perspective. Fixes: a43eec30 ("bpf: introduce bpf_perf_event_output() helper") Reported-by:
Jann Horn <jannh@google.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Alexei Starovoitov authored
On a system with >32Gbyte of phyiscal memory and infinite RLIMIT_MEMLOCK, the malicious application may overflow 32-bit bpf program refcnt. It's also possible to overflow map refcnt on 1Tb system. Impose 32k hard limit which means that the same bpf program or map cannot be shared by more than 32k processes. Fixes: 1be7f75d ("bpf: enable non-root eBPF programs") Reported-by:
-
David S. Miller authored
David Rivshin says: ==================== drivers: net: cpsw: phy-handle fixes This series fixes a number of related issues around using phy-handle properties in cpsw emac nodes. Patch 1 fixes a bug if more than one slave is used, and either slave uses the phy-handle property in the devicetree. Patch 2 fixes a NULL pointer dereference which can occur if a phy-handle property is used and of_phy_connect() return NULL, such as with a bad devicetree. Patch 3 fixes an issue where the phy-mode property would be ignored if a phy-handle property was used. This also fixes a bogus error message that would be emitted. Patch 4 fixes makes the binding documentation more explicit that exactly one PHY property should be used, and also marks phy_id as deprecated. Patch 5 cleans up the fixed-link case to work like the now-fixed phy-handle case. I have tested on the following hardware configurations: - (EVMSK) dual emac, phy_id property in both slaves - (EVMSK) dual emac, phy-handle property in both slaves - (EVMSK) a bad phy-handle property pointing to &mmc1 - (EVMSK) phy_id property with incorrect PHY address - (BeagleBoneBlack) single emac, phy_id property - (custom) single emac, fixed-link subnode Andrew Goodbody reported testing v2 on a board that doesn't use dual_emac mode, but with 2 PHYs using phy-handle properties [1]. Nicolas Chauvet reported testing v2 on an HP t410 (dm8148). Markus Brunner reported testing v1 on the following [2]: - emac0 with phy_id and emac1 with fixed phy - emac0 with phy-handle and emac1 with fixed phy - emac0 with fixed phy and emac1 with fixed phy [1] https://lkml.org/lkml/2016/4/22/537 [2] http://www.spinics.net/lists/netdev/msg357890.html ==================== Signed-off-by:
-
David Rivshin authored
If a fixed-link DT subnode is used, the phy_device was looked up so that a PHY ID string could be constructed and passed to phy_connect(). This is not necessary, as the device_node can be passed directly to of_phy_connect() instead. This reuses the same codepath as if the phy-handle DT property was used. Signed-off-by:
David Rivshin <drivshin@allworx.com> Tested-by:
Nicolas Chauvet <kwizart@gmail.com> Tested-by:
Andrew Goodbody <andrew.goodbody@cambrionix.com> Reviewed-by:
Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
David Rivshin authored
The phy-handle, phy_id, and fixed-link properties are mutually exclusive, and only one need be specified. Make this clear in the binding doc. Also mark the phy_id property as deprecated, as phy-handle should be used instead. Signed-off-by:
-
David Rivshin authored
The phy-mode emac property was only being processed in the phy_id or fixed-link cases. However if phy-handle was specified instead, an error message would complain about the lack of phy_id or fixed-link, and then jump past the of_get_phy_mode(). This would result in the PHY mode defaulting to MII, regardless of what the devicetree specified. Fixes: 9e42f715 ("drivers: net: cpsw: add phy-handle parsing") Signed-off-by:
-
David Rivshin authored
If an emac node has a phy-handle property that points to something which is not a phy, then a segmentation fault will occur when the interface is brought up. This is because while phy_connect() will return ERR_PTR() on failure, of_phy_connect() will return NULL. The common error check uses IS_ERR(), and so missed when of_phy_connect() fails. The NULL pointer is then dereferenced. Also, the common error message referenced slave->data->phy_id, which would be empty in the case of phy-handle. Instead, use the name of the device_node as a useful identifier. And in the phy_id case add the error code for completeness. Fixes: 9e42f715 ("drivers: net: cpsw: add phy-handle parsing") Signed-off-by:
-
David Rivshin authored
Commit 9e42f715 ("drivers: net: cpsw: add phy-handle parsing") saved the "phy-handle" phandle into a new cpsw_priv field. However, phy connections are per-slave, so the phy_node field should be in cpsw_slave_data rather than cpsw_priv. This would go unnoticed in a single emac configuration. But in dual_emac mode, the last "phy-handle" property parsed for either slave would be used by both of them, causing them both to refer to the same phy_device. Fixes: 9e42f715 ("drivers: net: cpsw: add phy-handle parsing") Signed-off-by:
-
Andreas Larsson authored
Signed-off-by:
Andreas Larsson <andreas@gaisler.com> Signed-off-by:
-
Jiri Benc authored
The collect metadata mode does not support GUE nor FOU. This might be implemented later; until then, we should reject such config. I think this is okay to be changed. It's unlikely anyone has such configuration (as it doesn't work anyway) and we may need a way to distinguish whether it's supported or not by the kernel later. For backwards compatibility with iproute2, it's not possible to just check the attribute presence (iproute2 always includes the attribute), the actual value has to be checked, too. Fixes: 2e15ea39 ("ip_gre: Add support to collect tunnel metadata.") Signed-off-by:
Jiri Benc <jbenc@redhat.com> Signed-off-by:
-
David S. Miller authored
Petko Manolov says: ==================== pegasus: correct buffer & packet sizes As noticed by Lincoln Ramsay <a1291762@gmail.com> some old (usb 1.1) Pegasus based devices may actually return more bytes than the specified in the datasheet amount. That would not be a problem if the allocated space for the SKB was equal to the parameter passed to usb_fill_bulk_urb(). Some poor bugger (i really hope it was not me, but 'git blame' is useless in this case, so anyway) decided to add '+ 8' to the buffer length parameter. Sometimes the usb transfer overflows and corrupts the socket structure, leading to kernel panic. The above doesn't seem to happen for newer (Pegasus2 based) devices which did help this bug to hide for so long. The new default is to not include the CRC at the end of each received package. So far CRC has been ignored which makes no sense to do it in a first place. The patch is against v4.6-rc5 and was tested on ADM8515 device by transferring multiple gigabytes of data over a couple of days without any complaints from the kernel. Please apply it to whatever net tree you deem fit. Changes since v1: - split the patch in two parts; - corrected the subject lines; Changes since v2: - do not append CRC by default (based on a discussion with Johannes Berg); ==================== Signed-off-by: -
Petko Manolov authored
The default Pegasus setup was to append the status and CRC at the end of each received packet. The status bits are used to update various stats, but CRC has been ignored. The new default is to not append CRC at the end of RX packets. Signed-off-by:
Petko Manolov <petkan@mip-labs.com> Signed-off-by:
-
Petko Manolov authored
usb_fill_bulk_urb() receives buffer length parameter 8 bytes larger than what's allocated by alloc_skb(); This seems to be a problem with older (pegasus usb-1.1) devices, which may silently return more data than the maximal packet length. Reported-by:
Lincoln Ramsay <a1291762@gmail.com> Signed-off-by:
-
David S. Miller authored
Jiri Benc says: ==================== gre: fix lwtunnel support This patchset fixes a few bugs in ipgre metadata mode implementation. As an example, in this setup: ip a a 192.168.1.1/24 dev eth0 ip l a gre1 type gre external ip l s gre1 up ip a a 192.168.99.1/24 dev gre1 ip r a 192.168.99.2/32 encap ip dst 192.168.1.2 ttl 10 dev gre1 ping 192.168.99.2 the traffic does not go through before this patchset and does as expected with it applied. v3: Back to v1 in order not to break existing users. Dropped patch 3, will be fixed in iproute2 instead. v2: Rejecting invalid configuration, added patch 3, dropped patch for ETH_P_TEB (will target net-next). ==================== Signed-off-by: -
Jiri Benc authored
In ipgre (i.e. not gretap) + collect metadata mode, the skb was assumed to contain Ethernet header and was encapsulated as ETH_P_TEB. This is not the case, the interface is ARPHRD_IPGRE and the protocol to be used for encapsulation is skb->protocol. Fixes: 2e15ea39 ("ip_gre: Add support to collect tunnel metadata.") Signed-off-by:
Pravin B Shelar <pshelar@ovn.org> Reviewed-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
-
Jiri Benc authored
In ipgre mode (i.e. not gretap) with collect metadata flag set, the tunnel is incorrectly assumed to be mGRE in NBMA mode (see commit 6a5f44d7). This is not the case, we're controlling the encapsulation addresses by lwtunnel metadata. And anyway, assigning dev->header_ops in collect metadata mode does not make sense. Although it would be more user firendly to reject requests that specify both the collect metadata flag and a remote/local IP address, this would break current users of gretap or introduce ugly code and differences in handling ipgre and gretap configuration. Keep the current behavior of remote/local IP address being ignored in such case. v3: Back to v1, added explanation paragraph. v2: Reject configuration specifying both remote/local address and collect metadata flag. Fixes: 2e15ea39 ("ip_gre: Add support to collect tunnel metadata.") Signed-off-by:
-
David S. Miller authored
Merge tag 'mac80211-for-davem-2016-04-27' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== Just a single fix, for a per-CPU memory leak in a (root user triggerable) error case. ==================== Signed-off-by:
-
Timur Tabi authored
Commit 13a56b44 ("at803x: Add support for hardware reset") added a work-around for a hardware bug on the AT8030. However, the work-around was being called for all 803x PHYs, even those that don't need it. Function at803x_link_change_notify() checks to make sure that it only resets the PHY on the 8030, but it makes more sense to not call that function at all if it isn't needed. Signed-off-by:
Timur Tabi <timur@codeaurora.org> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
git://git.open-mesh.org/linux-mergeDavid S. Miller authored
Antonio Quartulli says: ==================== In this patchset you can find the following fixes: 1) check skb size to avoid reading beyond its border when delivering payloads, by Sven Eckelmann 2) initialize last_seen time in neigh_node object to prevent cleanup routine from accidentally purge it, by Marek Lindner 3) release "recently added" slave interfaces upon virtual/batman interface shutdown, by Sven Eckelmann 4) properly decrease router object reference counter upon routing table update, by Sven Eckelmann 5) release queue slots when purging OGM packets of deactivating slave interface, by Linus Lüssing Patch 2 and 3 have no "Fixes:" tag because the offending commits date back to when batman-adv was not yet officially in the net tree. ==================== Signed-off-by: -
Christophe Jaillet authored
The size allocated for target->hwinfo and the number of bytes copied in it should be consistent. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Woojung Huh authored
At forced 100 Full & Half duplex mode, chip may fail to set mode correctly when cable is switched between long(~50+m) and short one. As workaround, set to 10 before setting to 100 at forced 100 F/H mode. Signed-off-by:
Woojung Huh <woojung.huh@microchip.com> Signed-off-by:
-
Woojung Huh authored
Fix rx_bytes, tx_bytes and tx_frames error in netdev.stats. - rx_bytes counted bytes excluding size of struct ethhdr. - tx_packets didn't count multiple packets in a single urb - tx_bytes included 8 bytes of extra commands. Signed-off-by:
-
Colin Ian King authored
The error return err is not initialized and there is a possibility that err is not assigned causing mv88e6xxx_port_bridge_join to return a garbage error return status. Fix this by initializing err to 0. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by:
-
Marcelo Ricardo Leitner authored
Fix casting in net_gso_ok. Otherwise the shift on gso_type << NETIF_F_GSO_SHIFT may hit the 32th bit and make it look like a INT_MIN, which is then promoted from signed to uint64 which is 0xffffffff80000000, resulting in wrong behavior when it is and'ed with the feature itself, as in: This test app: #include <stdio.h> #include <stdint.h> int main(int argc, char **argv) { uint64_t feature1; uint64_t feature2; int gso_type = 1 << 15; feature1 = gso_type << 16; feature2 = (uint64_t)gso_type << 16; printf("%lx %lx\n", feature1, feature2); return 0; } Gives: ffffffff80000000 80000000 So that this: return (features & feature) == feature; Actually works on more bits than expected and invalid ones. Fix is to promote it earlier. Issue noted while rebasing SCTP GSO patch but posting separetely as someone else may experience this meanwhile. Signed-off-by:Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
-
Neil Armstrong authored
When configured in fixed link, the DaVinci emac driver sets the priv->phydev to NULL and further ioctl calls to the phy_mii_ioctl() causes the kernel to crash. Cc: Brian Hutchinson <b.hutchman@gmail.com> Fixes: 1bb6aa56 ("net: davinci_emac: Add support for fixed-link PHY") Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
-
David S. Miller authored
Merge tag 'wireless-drivers-for-davem-2016-04-25' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for 4.6 ath9k * fix a couple release old throughput regression on ar9281 iwlwifi * add new device IDs for 8265 * fix a NULL pointer dereference when paging firmware asserts * remove a WARNING on gscan capabilities * fix MODULE_FIRMWARE for 8260 ==================== Signed-off-by:
-
Bert Kenward authored
Add myself and Edward Cree as maintainers. Remove Shradha Shah, who is on extended leave. Cc: David S. Miller <davem@davemloft.net> Cc: Edward Cree <ecree@solarflare.com> Cc: Shradha Shah <sshah@solarflare.com> Signed-off-by:
Bert Kenward <bkenward@solarflare.com> Acked-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
-
Jon Cooper authored
When certain firmware variants are selected (via the sfboot utility) the SFC7000 and SFC8000 series NICs don't support RSS. The driver still tries (and fails) to insert filters with the RSS flag, and the NIC fails to pass traffic. When the firmware reports RSS_LIMITED suppress allocating a default RSS context. The absence of an RSS context is picked up in filter insertion and RSS flags are discarded. Signed-off-by:
-
Stanislaw Gruszka authored
napi_disable() can not be called with bh disabled, move locking just around myri10ge_ss_lock_napi() . Patches fixes following bug: [ 114.278378] BUG: sleeping function called from invalid context at net/core/dev.c:4383 <snip> [ 114.313712] Call Trace: [ 114.314943] [<ffffffff817010ce>] dump_stack+0x19/0x1b [ 114.317673] [<ffffffff810ce7f3>] __might_sleep+0x173/0x230 [ 114.320566] [<ffffffff815b3117>] napi_disable+0x27/0x90 [ 114.323254] [<ffffffffa01e437f>] myri10ge_close+0xbf/0x3f0 [myri10ge] Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Hyong-Youb Kim <hykim@myri.com> Signed-off-by:
-
Eric Engestrom authored
Signed-off-by:
Eric Engestrom <eric@engestrom.ch> Signed-off-by:
-
- 27 Apr, 2016 3 commits
-
-
David S. Miller authored
Michael Chan says: ==================== bnxt_en: Bug fixes for net. Only use MSIX on VF, and fix rx page buffers on architectures with PAGE_SIZE >= 64K. ==================== Signed-off-by: -
Michael Chan authored
If PAGE_SIZE is bigger than BNXT_RX_PAGE_SIZE, that means the native CPU page is bigger than the maximum length of the RX BD. Divide the page into multiple 32K buffers for the aggregation ring. Add an offset field in the bnxt_sw_rx_agg_bd struct to keep track of the page offset of each buffer. Since each page can be referenced by multiple buffer entries, call get_page() as needed to get the proper reference count. Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Michael Chan authored
The RX BD length field of this device is 16-bit, so the largest buffer size is 65535. For LRO and GRO, we allocate native CPU pages for the aggregation ring buffers. It won't work if the native CPU page size is 64K or bigger. We fix this by defining BNXT_RX_PAGE_SIZE to be native CPU page size up to 32K. Replace PAGE_SIZE with BNXT_RX_PAGE_SIZE in all appropriate places related to the rx aggregation ring logic. The next patch will add additional logic to divide the page into 32K chunks for aggrgation ring buffers if PAGE_SIZE is bigger than BNXT_RX_PAGE_SIZE. Signed-off-by:
-
