- 22 Dec, 2013 13 commits
-
-
Hannes Frederic Sowa authored
We report different pmtu values back on the first write and on further writes on an corked socket. Also don't include the dst.header_len (respectively exthdrlen) as this should already be dealt with by the interface mtu of the outgoing (virtual) interface and policy of that interface should dictate if fragmentation should happen. Instead reduce the pmtu data by IP options as we do for IPv6. Make the same changes for ip_append_data, where we did not care about options or dst.header_len at all. Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Mugunthan V N authored
During checking the interrupts with "cat /proc/interrupts", it is showing device name as (null), this change was done with commit id aa1a15e2 where request_irq is changed to devm_request_irq also changing the irq name from platform device name to net device name, but the net device is not registered at this point with the network frame work, so devm_request_irq is called with device name as NULL, by which it is showed as "(null)" in "cat /proc/interrupts". So this patch changes back irq name to platform device name itself in devm_request_irq so that the device name shows as below. Previous to this patch root@am335x-evm:~# cat /proc/interrupts CPU0 28: 2265 INTC 12 edma 30: 80 INTC 14 edma_error 56: 0 INTC 40 (null) 57: 1794 INTC 41 (null) 58: 7 INTC 42 (null) 59: 0 INTC 43 (null) With this patch root@am335x-evm:~# cat /proc/interrupts CPU0 28: 213 INTC 12 edma 30: 9 INTC 14 edma_error 56: 0 INTC 40 4a100000.ethernet 57: 16097 INTC 41 4a100000.ethernet 58: 11964 INTC 42 4a100000.ethernet 59: 0 INTC 43 4a100000.ethernet Signed-off-by:
Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by:
-
David S. Miller authored
Hariprasad Shenai says: ==================== This patch series provides miscelleneous fixes for Chelsio T4/T5 adapters related to server entries and server filter entries. Also, fixes a bug in ULD (Upper Level Driver) like iw_cxgb4 where-in it calculates wrong tuple values on T5 adapter. So, a new API cxgb4_select_ntuple is exported so as to enable Upper Lever Drivers like iw_cxgb4 to correctly calculate tuple values. The patches series is created agains David Miller's 'net' tree. And includes patches on cxgb4 and iw_cxgb4 driver. Patch 8/8 (RDMA-cxgb4-Use-cxgb4_select_ntuple-to-correctly-calc.patch) has a build dependency on Patch 5/8 (cxgb4-Add-API-to-correctly-calculate-tuple-fields.patch). Also, Patch 6/8 (RDMA-cxgb4-Calculate-the-filter-server-TID-properly.patch) has a functional dependency on Patch 3/8 (cxgb4-Assign-filter-server-TIDs-properly.patch) We would like to request this patch series to get merged via David Miller's 'net' tree. We have included all the maintainers of respective drivers. Kindly review the change and let us know in case of any review comments. V2 changes: - Removed earlier patch which added sftids_in_use counter. However, the counter was actually not used anywhere in this patch series. Thanks to David Miller for spotting this. We have dropped this patch in V2 and will submit a more complete patch which uses sftids_in_use counter later on. - Fixed a 'checkpatch.pl --strict' warning on Patch 5/8 (cxgb4-Add-API-to-correctly-calculate-tuple-fields.patch). - Removed some un-used #defines from Patch 5/8 (cxgb4-Add-API-to-correctly-calculate-tuple-fields.patch). ==================== Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com>
-
Kumar Sanghvi authored
Signed-off-by:
Kumar Sanghvi <kumaras@chelsio.com> Signed-off-by:
Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by:
-
Kumar Sanghvi authored
Signed-off-by:
-
Kumar Sanghvi authored
Based on original work by Santosh Rastapur <santosh@chelsio.com> Signed-off-by:
-
Kumar Sanghvi authored
Adds API cxgb4_select_ntuple so as to enable Upper Level Drivers to correctly calculate the tuple fields. Adds constant definitions for TP_VLAN_PRI_MAP for the Compressed Filter Tuple field widths and structures and uses them. Also, the CPL Parameters field for T5 is 40 bits so we need to prototype cxgb4_select_ntuple() to calculate and return u64 values. Based on original work by Casey Leedom <leedom@chelsio.com> Signed-off-by:
-
Kumar Sanghvi authored
IPv6 uses 2 TIDs with CLIP enabled and 4 TIDs without CLIP. Currently we are incrementing STIDs in use by 1 for both IPv4 and IPv6 which is wrong. Further, driver currently does not have interface to query if CLIP is programmed for particular IPv6 address. So, in this patch we increment/decrement TIDs in use by 4 for IPv6 assuming absence of CLIP. Such assumption keeps us on safe side and we don't end up allocating more stids for IPv6 than actually supported. Based on original work by Santosh Rastapur <santosh@chelsio.com> Signed-off-by:
-
Kumar Sanghvi authored
The LE workaround code is incorrectly reusing the TCAM TIDs (meant for allocation by firmware in case of hash collisions) for filter servers. This patch assigns the filter server TIDs properly starting from sftid_base index. Based on original work by Santosh Rastapur <santosh@chelsio.com> Signed-off-by:
-
Kumar Sanghvi authored
We were creating LE Workaround Server Filters without specifying IPPROTO_TCP (6) in the filters (when F_PROTOCOL is set in TP_VLAN_PRI_MAP). This meant that UDP packets with matching IP Addresses/Ports would get caught up in the filter and be delivered to ULDs like iw_cxgb4. So, include the protocol information in the server filter properly. Based on original work by Casey Leedom <leedom@chelsio.com> Signed-off-by:
-
Kumar Sanghvi authored
When creating offload server entries, an IPv6 passive connection request can trigger a reply with a null STID, whereas the driver would expect the reply 'STID to match the value used for the request. This happens due to h/w limitation on T4 and T5. This patch ensures that STID 0 is never used if the stid range starts from zero. Based on original work by Santosh Rastapur <santosh@chelsio.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wirelessDavid S. Miller authored
John W. Linville says: ==================== Please consider pulling this batch of fixes for the 3.13 stream... For the mac80211 bits, Johannes says: "Here's a fix for another potential radiotap parser buffer overrun thanks to Evan Huus, and a fix for a cfg80211 warning in a certain corner case (reconnecting to the same BSS)." For the bluetooth bits, Gustavo says: "Two patches in this pull request. An important fix from Marcel in the permission check for HCI User Channels, there was a extra check for CAP_NET_RAW, and it was now removed. These channels should only require CAP_NET_ADMIN. The other patch is a device id addition." On top of that... Sujith Manoharan provides a workaround for a hardware problem that can result in lost interrupts. Larry Finger fixes an oops when unloading the rtlwifi driver (Red Hat bug 852761). Mathy Vanhoef fixes a somewhat minor MAC address privacy issue (CVE-2013-4579). ==================== Signed-off-by: -
Haiyang Zhang authored
Moving the register_netdev to the end of probe to prevent possible open call happens before NetVSP is connected. Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
- 20 Dec, 2013 5 commits
-
-
John W. Linville authored
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
-
Wang Weidong authored
Check the return value of request_module during dccp_probe initialisation, bail out if that call fails. Signed-off-by:
Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by:
Wang Weidong <wangweidong1@huawei.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/netDavid S. Miller authored
Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates This series contains updates to net, ixgbe and e1000e. David provides compiler fixes for e1000e. Don provides a fix for ixgbe to resolve a compile warning. John provides a fix to net where it is useful to be able to walk all upper devices when bringing a device online where the RTNL lock is held. In this case, it is safe to walk the all_adj_list because the RTNL lock is used to protect the write side as well. This patch adds a check to see if the RTNL lock is held before throwing a warning in netdev_all_upper_get_next_dev_rcu(). ==================== Signed-off-by: -
Leigh Brown authored
This version corrects the whitespace issue. orion_mdio_wait_ready uses wait_event_timeout to wait for the SMI interrupt to fire. wait_event_timeout waits for between "timeout - 1" and "timeout" jiffies. In this case a 1ms timeout when HZ is 1000 results in a wait of 0 to 1 jiffies, causing premature timeouts. This fix ensures a minimum timeout of 2 jiffies, ensuring wait_event_timeout will always wait at least 1 jiffie. Issue reported by Nicolas Schichan. Tested-by:
Nicolas Schichan <nschichan@freebox.fr> Signed-off-by:
Leigh Brown <leigh@solinno.co.uk> Signed-off-by:
-
Betty Dall authored
The function atl1c_reset_pcie() does not check the return from pci_find_ext_cabability() where it is getting the postion of the PCI_EXT_CAP_ID_ERR. It is possible for the return to be 0. Signed-off-by:
Betty Dall <betty.dall@hp.com> Signed-off-by:
-
- 19 Dec, 2013 7 commits
-
-
Li RongQing authored
ip6_rt_copy only sets dst.from if ort has flag RTF_ADDRCONF and RTF_DEFAULT. but the prefix routes which did get installed by hand locally can have an expiration, and no any flag combination which can ensure a potential from does never expire, so we should always set the new created dst's from. This also fixes the new created dst is always expired since the ort, which is created by RA, maybe has RTF_EXPIRES and RTF_ADDRCONF, but no RTF_DEFAULT. Suggested-by:
Li RongQing <roy.qing.li@gmail.com> Acked-by:
-
Eric Dumazet authored
skb_tx_timestamp(skb) should be called _before_ TX completion has a chance to trigger, otherwise it is too late and we access freed memory. Signed-off-by:
Eric Dumazet <edumazet@google.com> Fixes: de5fb0a0 ("net: fec: put tx to napi poll function to fix dead lock") Cc: Frank Li <Frank.Li@freescale.com> Cc: Richard Cochran <richardcochran@gmail.com> Acked-by:
Richard Cochran <richardcochran@gmail.com> Acked-by:
Frank Li <Frank.Li@freescale.com> Signed-off-by:
-
Michal Schmidt authored
"valid ME register value" is not an error. It should be logged for debugging only. Signed-off-by:
Michal Schmidt <mschmidt@redhat.com> Acked-by:
Yuval Mintz <yuvalmin@broadcom.com> Signed-off-by:
-
Salva Peiró authored
The yam_ioctl() code fails to initialise the cmd field of the struct yamdrv_ioctl_cfg. Add an explicit memset(0) before filling the structure to avoid the 4-byte info leak. Signed-off-by:
Salva Peiró <speiro@ai2.upv.es> Signed-off-by:
-
Wenliang Fan authored
The local variable 'bi' comes from userspace. If userspace passed a large number to 'bi.data.calibrate', there would be an integer overflow in the following line: s->hdlctx.calibrate = bi.data.calibrate * s->par.bitrate / 16; Signed-off-by:
Wenliang Fan <fanwlexca@gmail.com> Signed-off-by:
-
Wei Yongjun authored
'err' is overwrited to 0 after maybe_pull_tail() call, so the error code was not set if skb_partial_csum_set() call failed. Fix to return error -EPROTO from those error handling case instead of 0. Fixes: d52eb0d4 ('xen-netback: make sure skb linear area covers checksum field') Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Acked-by:
Wei Liu <wei.liu2@citrix.com> Signed-off-by:
-
Daniel Borkmann authored
Jakub reported while working with nlmon netlink sniffer that parts of the inet_diag_sockid are not initialized when r->idiag_family != AF_INET6. That is, fields of r->id.idiag_src[1 ... 3], r->id.idiag_dst[1 ... 3]. In fact, it seems that we can leak 6 * sizeof(u32) byte of kernel [slab] memory through this. At least, in udp_dump_one(), we allocate a skb in ... rep = nlmsg_new(sizeof(struct inet_diag_msg) + ..., GFP_KERNEL); ... and then pass that to inet_sk_diag_fill() that puts the whole struct inet_diag_msg into the skb, where we only fill out r->id.idiag_src[0], r->id.idiag_dst[0] and leave the rest untouched: r->id.idiag_src[0] = inet->inet_rcv_saddr; r->id.idiag_dst[0] = inet->inet_daddr; struct inet_diag_msg embeds struct inet_diag_sockid that is correctly / fully filled out in IPv6 case, but for IPv4 not. So just zero them out by using plain memset (for this little amount of bytes it's probably not worth the extra check for idiag_family == AF_INET). Similarly, fix also other places where we fill that out. Reported-by:
Jakub Zawadzki <darkjames-ws@darkjames.pl> Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
-
- 18 Dec, 2013 15 commits
-
-
Eric Dumazet authored
While testing my changes for TSO support in SIT devices, I was using sit0 tunnel which appears to include nopmtudisc flag. But using : ip tun add sittun mode sit remote $REMOTE_IPV4 local $LOCAL_IPV4 \ dev $IFACE We get a tunnel which rejects too long packets because of the mtu check which is not yet GSO aware. erd:~# ip tunnel sittun: ipv6/ip remote 10.246.17.84 local 10.246.17.83 ttl inherit 6rd-prefix 2002::/16 sit0: ipv6/ip remote any local any ttl 64 nopmtudisc 6rd-prefix 2002::/16 This patch is based on an excellent report from Michal Shmidt. In the future, we probably want to extend the MTU check to do the right thing for GSO packets... Fixes: ("61c1db7f ipv6: sit: add GSO/TSO support") Reported-by: -
Hannes Frederic Sowa authored
Sockets marked with IPV6_PMTUDISC_PROBE (or later IPV6_PMTUDISC_INTERFACE) don't respect this setting when the outgoing interface supports UFO. We had the same problem in IPv4, which was fixed in commit daba287b ("ipv4: fix DO and PROBE pmtu mode regarding local fragmentation with UFO/CORK"). Also IPV6_DONTFRAG mode did not care about already corked data, thus it may generate a fragmented frame even if this socket option was specified. It also did not care about the length of the ipv6 header and possible options. In the error path allow the user to receive the pmtu notifications via both, rxpmtu method or error queue. The user may opted in for both, so deliver the notification to both error handlers (the handlers check if the error needs to be enqueued). Also report back consistent pmtu values when sending on an already cork-appended socket. Signed-off-by:
-
Peter Korsgaard authored
Certain dm962x revisions contain an bug, where if a USB bulk transfer retry (E.G. if bulk crc mismatch) happens right after a transfer with odd or maxpacket length, the internal tx hardware fifo gets out of sync causing the interface to stop working. Work around it by adding up to 3 bytes of padding to ensure this situation cannot trigger. This workaround also means we never pass multiple-of-maxpacket size skb's to usbnet, so the length adjustment to handle usbnet's padding of those can be removed. Cc: <stable@vger.kernel.org> Reported-by:
Joseph Chang <joseph_chang@davicom.com.tw> Signed-off-by:
Peter Korsgaard <peter@korsgaard.com> Signed-off-by:
-
Peter Korsgaard authored
The driver nowadays also support dm9620/dm9621a based USB 2.0 ethernet adapters, so adjust module/driver description and Kconfig help text to match. Signed-off-by:
-
Peter Korsgaard authored
dm9620/dm9621a require room for 4 byte padding even in dm9601 (3 byte header) mode. Cc: <stable@vger.kernel.org> Signed-off-by:
-
Peter Korsgaard authored
dm9621a is functionally identical to dm9620, so the existing handling can directly be used. Thanks to Davicom for sending me a dongle. Signed-off-by:
-
Timo Teräs authored
ipgre_header_parse() needs to parse the tunnel's ip header and it uses mac_header to locate the iphdr. This got broken when gre tunneling was refactored as mac_header is no longer updated to point to iphdr. Introduce skb_pop_mac_header() helper to do the mac_header assignment and use it in ipgre_rcv() to fix msg_name parsing. Bug introduced in commit c5441932 (GRE: Refactor GRE tunneling code.) Cc: Pravin B Shelar <pshelar@nicira.com> Signed-off-by:
Timo Teräs <timo.teras@iki.fi> Signed-off-by:
-
Mugunthan V N authored
This patch adds support for enabling In Band mode in 10 mbps speed. RGMII supports 1 Gig and 100 mbps mode for Forced mode of operation. For 10mbps mode it should be configured to in band mode so that link status, duplexity and speed are determined from the RGMII input data stream Signed-off-by:
-
David S. Miller authored
Ding Tianhong says: ==================== Jay Vosburgh said that the bond_3ad_adapter_speed_changed and bond_3ad_adapter_duplex_changed is called with RTNL only, and the functions will modify the port's information with no further locking, they will not mutex against bond state machine and incoming LACPDU which do not hold RTNL, So I add port lock to protect the port information. But they are not critical bugs, they exist since day one, and till now they have never been hit and reported, because change for speed and duplex is very rare, and will not occur critical problem. The comments in the function is very old, cleanup the comments together. ==================== Signed-off-by:
Jay Vosburgh <fubar@us.ibm.com> Signed-off-by:
-
dingtianhong authored
The bond_3ad_handle_link_change is called with RTNL only, and the function will modify the port's information with no further locking, it will not mutex against bond state machine and incoming LACPDU which do not hold RTNL, So I add __get_state_machine_lock to protect the port. But it is not a critical bug, it exist since day one, and till now it has never been hit and reported, because changes to speed is very rare, and will not occur critical problem. The comments in the function is very old, cleanup it and add a new pr_debug to debug the port message. Signed-off-by:
Ding Tianhong <dingtianhong@huawei.com> Signed-off-by:
-
dingtianhong authored
Jay Vosburgh said that the bond_3ad_adapter_duplex_changed is called with RTNL only, and the function will modify the port's information with no further locking, it will not mutex against bond state machine and incoming LACPDU which do not hold RTNL, So I add __get_state_machine_lock to protect the port. But it is not a critical bug, it exist since day one, and till now it has never been hit and reported, because changes to speed is very rare, and will not occur critical problem. The comments in the function is very old, cleanup it. Suggested-by:
-
dingtianhong authored
Jay Vosburgh said that the bond_3ad_adapter_speed_changed is called with RTNL only, and the function will modify the port's information with no further locking, it will not mutex against bond state machine and incoming LACPDU which do not hold RTNL, So I add __get_state_machine_lock to protect the port. But it is not a critical bug, it exist since day one, and till now it has never been hit and reported, because changes to speed is very rare, and will not occur critical problem. The comment in the function is very old, cleanup it. Suggested-by:
-
-
Don Skidmore authored
If CONFIG_PCI_IOV isn't defined we get an "unused variable" warining so now wrap the variable declaration like it's usage already was. Signed-off-by:
Don Skidmore <donald.c.skidmore@intel.com> Acked-by:
John Fastabend <john.r.fastabend@intel.com> Tested-by:
Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
David Ertman authored
This patch addresses a mis-match between the declaration and usage of the e1000_suspend and e1000_resume functions. Previously, these functions were declared in a CONFIG_PM_SLEEP wrapper, and then utilized within a CONFIG_PM wrapper. Both the declaration and usage will now be contained within CONFIG_PM wrappers. Signed-off-by:
Dave Ertman <davidx.m.ertman@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
-
