- Nov 04, 2013
-
-
Eric Dumazet authored
Joby Poriyath provided a xen-netback patch to reduce the size of xenvif structure as some netdev allocation could fail under memory pressure/fragmentation. This patch is handling the problem at the core level, allowing any netdev structures to use vmalloc() if kmalloc() failed. As vmalloc() adds overhead on a critical network path, add __GFP_REPEAT to kzalloc() flags to do this fallback only when really needed. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Joby Poriyath <joby.poriyath@citrix.com> Cc: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Daniel Borkmann says: ==================== SCTP fix/updates Please see patch 5 for the main description/motivation, the rest just brings in the needed functionality for that. Although this is actually a fix, I've based it against net-next as some additional work for fixing it was needed. ==================== Acked-by:
Neil Horman <nhorman@tuxdriver.com> Acked-by:
Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Daniel Borkmann authored
This fixes an outstanding bug found through IPVS, where SCTP packets with skb->data_len > 0 (non-linearized) and empty frag_list, but data accumulated in frags[] member, are forwarded with incorrect checksum letting SCTP initial handshake fail on some systems. Linearizing each SCTP skb in IPVS to prevent that would not be a good solution as this leads to an additional and unnecessary performance penalty on the load-balancer itself for no good reason (as we actually only want to update the checksum, and can do that in a different/better way presented here). The actual problem is elsewhere, namely, that SCTP's checksumming in sctp_compute_cksum() does not take frags[] into account like skb_checksum() does. So while we are fixing this up, we better reuse the existing code that we have anyway in __skb_checksum() and use it for walking through the data doing checksumming. This will not only fix this issue, but also consolidates some SCTP code with core sk_buff code, bringing it closer together and removing respectively avoiding reimplementation of skb_checksum() for no good reason. As crc32c() can use hardware implementation within the crypto layer, we leave that intact (it wraps around / falls back to e.g. slice-by-8 algorithm in __crc32c_le() otherwise); plus use the __crc32c_le_combine() combinator for crc32c blocks. Also, we remove all other SCTP checksumming code, so that we only have to use sctp_compute_cksum() from now on; for doing that, we need to transform SCTP checkumming in output path slightly, and can leave the rest intact. Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Daniel Borkmann authored
Currently, skb_checksum walks over 1) linearized, 2) frags[], and 3) frag_list data and calculats the one's complement, a 32 bit result suitable for feeding into itself or csum_tcpudp_magic(), but unsuitable for SCTP as we're calculating CRC32c there. Hence, in order to not re-implement the very same function in SCTP (and maybe other protocols) over and over again, use an update() + combine() callback internally to allow for walking over the skb with different algorithms. Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Daniel Borkmann authored
We already have 100 test cases for crcs itself, so split the test buffer with a-prio known checksums, and test crc of two blocks against crc of the whole block for the same results. Output/result with CONFIG_CRC32_SELFTEST=y: [ 2.687095] crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64 [ 2.687097] crc32: self tests passed, processed 225944 bytes in 278177 nsec [ 2.687383] crc32c: CRC_LE_BITS = 64 [ 2.687385] crc32c: self tests passed, processed 225944 bytes in 141708 nsec [ 7.336771] crc32_combine: 113072 self tests passed [ 12.050479] crc32c_combine: 113072 self tests passed [ 17.633089] alg: No test for crc32 (crc32-pclmul) Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Cc: linux-kernel@vger.kernel.org Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Daniel Borkmann authored
This patch adds a combinator to merge two or more crc32{,c}s into a new one. This is useful for checksum computations of fragmented skbs that use crc32/crc32c as checksums. The arithmetics for combining both in the GF(2) was taken and slightly modified from zlib. Only passing two crcs is insufficient as two crcs and the length of the second piece is needed for merging. The code is made generic, so that only polynomials need to be passed for crc32_le resp. crc32c_le. Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Cc: linux-kernel@vger.kernel.org Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Daniel Borkmann authored
This is nothing more but a whitepace cleanup, as 80 chars is not a hard but soft limit, and otherwise makes the test cases array really look ugly. So fix it up. Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Cc: linux-kernel@vger.kernel.org Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Nov 02, 2013
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-nextDavid S. Miller authored
Conflicts: net/xfrm/xfrm_policy.c Minor merge conflict in xfrm_policy.c, consisting of overlapping changes which were trivial to resolve. Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Dan Carpenter authored
There is an extra semi-colon so bond_get_size() doesn't return the correct value. Fixes: ec76aa49 ('bonding: add Netlink support active_slave option') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Veaceslav Falico <vfalico@redhat.com> Reviewed-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Bjørn Mork says: ==================== cdc_ncm: many small and mostly trivial fixes This series ended up longer than expected, and it is still not complete. There is more to come when time allows... Most changes are trivial. Notable non-trivial changes are - removed filtering of identical speed notifications - tx_max calulation is changed to count the pad byte if necessary, and respect the device limit as an absolute upper limit even if it is too low according to the spec - remove the bug preventing SET_MAX_DATAGRAM_SIZE from having any effect - drop the pad-to-max if ZLPs are enabled - the driver specific VERSION is dropped - dev->hard_mtu is set to tx_max instead of max_datagram_size causing usbnet to calculate the qlen based on the real max size of tx skbs This series has been tested, along with the previously posted cdc_mbim series, on the NCM and MBIM devices I have: - Ericsson F5521gw (NCM) - Huawei E367 (MBIM) - D-Link DWM-156 A7 (MBIM w/ too low dwNtb{In,Out}MaxSize bug) - Sierra Wireless MC7710 (MBIM w/ ZLP and CDC Union bugs) Apart from the D-Link modem dropping a lot less oversized frames with the fix dedicated to it, there are no end user noticable functional changes as a result of this series. But all the non-trivial changes I listed above are of course detectable by users looking at that specific area (except maybe the removed speed notification, which requires a device sending duplicates to be noticable - I don't have any such device). ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
There are MBIM devices out there reporting dwNtbInMaxSize=2048 dwNtbOutMaxSize=2048 and since the spec require a datagram max size of at least 2048, this means that a full sized datagram will never fit. Still, sending larger NTBs than the device supports is not going to help. We do not have any other options than either a) refusing to bindi, or b) respect the insanely low value. Alternative b will at least make these devices work, so go for it. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
Make it a bit easier for users to figure out what goes wrong when bind fails. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
Most setup errors are ignored to ensure maximum firmware compatibilty. But GET_NTB_PARAMETERS and the functional descriptors are required. Use proper error codes and log level if these fail. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
Rewriting the "set max datagram" part of dc_ncm_setup to separate the selection and validatation of the size from the code which optionally informs the device of this value. This ensures that we use the correct value regardless of device support for the get and set commands. Removing some of the many indent levels while doing this to make the code more readable. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
Converting the constants used in these comparisons at build time instead of converting the variables for every received frame at run time. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
These signatures are well known bit patterns, mostly made up of ascii characters. Mentally parsing works best if they are printed in hex. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
Take advantage of standard device name prefixing and netdevice msglvl control where possible. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
Fix cut'n'paste typo. Log the bogus length and not the irrelevant signature. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
usbnet use the hard_mtu value for sizing the tx queue and nothing else. We will be transmitting buffers of up to tx_max size, so that's the proper value to give usbnet. The individual datagram size is completely irrelevant here. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
No need to keep this code duplicated from usbnet. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
These functions were merely wrappers around the usbnet variants. Remove them. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
Padding NTBs to max size is part of the support for devices optimizing their DMA transfers. This optimization depends on max sized NTBs not being ZLP terminated. So we are much better off dropping the padding if we are going to send a ZLP anyway. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
The probed interface must be the master/control interface of the function. Make this explicit and simplify redundant tests. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
header_desc was completely unused and union_desc was never used outside cdc_ncm_bind_common. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
We need to inform the device about the *new* value, not the old one. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
Moving the call to cdc_ncm_setup() after the endpoint setup removes the last remaining reference to ncm_parm outside cdc_ncm_setup. Collecting all the ncm_parm based calculations in cdc_ncm_setup improves readability. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
These fields are only used to prevent printing the same speeds multiple times if we receive multiple identical speed notifications. The value of these printk's is questionable, and even more so when we filter out some of the notifications sent us by the firmware. If we are going to print any of these, then we should print them all. Removing little used fields is a bonus. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
We already use the usbnet udev field everywhere this could have been used. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
Too many pointers back and forth are likely to confuse developers, creating subtle bugs whenever we forget to syncronize them all. As a usbnet driver, we should stick with the standard struct usbnet fields as much as possible. The netdevice is one such field. Cc: Greg Suarez <gsuarez@smithmicro.com> Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
No need to duplicate stuff already in the common usbnet struct. We still need to keep our special find_endpoints function because we need explicit control over the selected altsetting. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
This is always a duplicate of the "control" field. It causes confusion wrt intf_data updates and cleanups. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
This makes it a lot easier to test modified versions Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
We can avoid the costly division for the common case where we pad the frame to tx_max size as long as we ensure that tx_max is either the device specified dwNtbOutMaxSize or not a multiplum of wMaxPacketSize. Using the preconverted 'maxpacket' field avoids converting wMaxPacketSize to CPU endianness for every transmitted frame And since we only will hit the one byte padding rule for short frames, we can drop testing the skb for tailroom. The change means that tx_max now represents the real maximum skb size, enabling us to allocate the correct size instead of always making room for one extra byte. Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
A number of devices in the wild have turned out to require ZLPs. Even if this is a spec violation, our priority is to make any device work as good as possible. Devices needing ZLPs will fail to receive any full sized frame we send. On the other hand, devices which do not need the ZLP will still work if we send them. This gives us no other option than sending ZLPs by default. This will prevent devices conforming to the spec from making the optimizations which are possible without ZLPs. Adding known such devices to a whitelist, to avoid the possible negative impact of the new spec violating default. Cc: Greg Suarez <gsuarez@smithmicro.com> Cc: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
MBIM is a point-to-point protocol transporting raw IP packets with no L2 headers. Only IPv4 and IPv6 are supported. ARP in particular is not, which is quite logical given the lack of L2 headers. The driver still emulates an ethernet interface, dropping all unsupported protocols, and avoiding neigbour resolving by setting the IFF_NOARP flag. The MBIM specification does not explicitly forbid IPv6 Neighbor Discovery, and it seems the other OS support will respond to Neighbor Solicitations on MBIM links. There are therefore buggy devices out there, which despite the pointlessness, still require Neighbor Discovery for IPv6 over MBIM. This is incompatible with the IFF_NOARP flag which disables both ARP and ND. We cannot support ARP in any case, so we have to keep that flag. This patch implements a workaround for the buggy devices, letting the driver respond directly to Neighbor Solicitations from the device. This is not optimal, but will have minimal effect on any sane device. Cc: Greg Suarez <gsuarez@smithmicro.com> Reported-and-tested-by:
Thomas Schäfer <tschaefer@t-online.de> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ben Boeckel authored
Signed-off-by:
Ben Boeckel <mathstuf@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ben Boeckel authored
Also snipes some trailing whitespace. Signed-off-by:
Ben Boeckel <mathstuf@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ben Boeckel authored
Also snipes some whitespace errors. Signed-off-by:
Ben Boeckel <mathstuf@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ben Boeckel authored
Signed-off-by:
Ben Boeckel <mathstuf@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-