- 20 Jan, 2017 40 commits
-
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Printing console messages is not helpful when system is out of memory; and can be disastrous with netconsole. Instead keep statistics of these anomalous conditions. Signed-off-by:
Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 4323b47c) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Make netvsc on vmbus behave more like PCI. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 The variable m_ret is only used in one basic block. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 No caller checks the return value. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Break the different cases, code is cleaner if broken up Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Rearrange the transmit routine to eliminate goto's and unnecessary boolean variables. Use standard functions to test for vlan tag. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Move initialization to allocate where other fields are initialized. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Always returns 0 and no callers check. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Don't hard code size of array of NDIS versions. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Several new functions were introduced into hyperv.h but only used in one file. Move them and let compiler decide on inline. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Fix most of the complaints about the style of the code. Things like extra blank lines and return statements. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Better to use kcalloc rather than kzalloc and multiply for an array. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 The function get_netvsc_net_device had conditional locking. This was unnecessary, incorrect, but harmless. It was unnecessary since the code is only called from netlink netdev event callback where RTNL is always acquired before the callbacks are run. It was incorrect because of use of trylock and then continuing. Fix by replacing with proper assertion. Signed-off-by:
-
Wei Yongjun authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Use list_move_tail() instead of list_del() + list_add_tail(). No functional change intended Signed-off-by:
Wei Yongjun <weiyj.lk@gmail.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> (cherry picked from commit 4f1cb01a) Signed-off-by:
-
Haiyang Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1650059 The existing code uses busy retry when unable to send out receive completions due to full ring buffer. It also gives up retrying after limit is reached, and causes receive buffer slots not being recycled. This patch implements batching of receive completions. It also prevents dropping receive completions due to full ring buffer. Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by:
-
Haiyang Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1650059 On Hyper-V host 2016 and later, VMs gets an event message of the physical link speed when vSwitch is changed. This patch handles this message, so the updated link speed can be reported by ethtool. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Haiyang Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1650059 The physical link speed value will be reported by ethtool command. The real speed is available from Windows 2016 host or later. Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Currently, all newly added memory blocks remain in 'offline' state unless someone onlines them, some linux distributions carry special udev rules like: SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online" to make this happen automatically. This is not a great solution for virtual machines where memory hotplug is being used to address high memory pressure situations as such onlining is slow and a userspace process doing this (udev) has a chance of being killed by the OOM killer as it will probably require to allocate some memory. Introduce default policy for the newly added memory blocks in /sys/devices/system/memory/auto_online_blocks file with two possible values: "offline" which preserves the current behavior and "online" which causes all newly added memory blocks to go online as soon as they're added. The default is "offline". Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Daniel Kiper <daniel.kiper@oracle.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Tang Chen <tangchen@cn.fujitsu.com> Cc: David Vrabel <david.vrabel@citrix.com> Acked-by:
David Rientjes <rientjes@google.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Xishi Qiu <qiuxishi@huawei.com> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: "K. Y. Srinivasan" <kys@microsoft.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Kay Sievers <kay@vrfy.org> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 31bc3858) Signed-off-by:
-
Thomas Falcon authored
BugLink: http://bugs.launchpad.net/bugs/1655420 Include calculations to compute the number of segments that comprise an aggregated large packet. Signed-off-by:
Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Reviewed-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Reviewed-by:
Jonathan Maxwell <jmaxwell37@gmail.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by:
-
Thomas Falcon authored
BugLink: http://bugs.launchpad.net/bugs/1655420 This patch is based on an earlier one submitted by Jon Maxwell with the following commit message: "We recently encountered a bug where a few customers using ibmveth on the same LPAR hit an issue where a TCP session hung when large receive was enabled. Closer analysis revealed that the session was stuck because the one side was advertising a zero window repeatedly. We narrowed this down to the fact the ibmveth driver did not set gso_size which is translated by TCP into the MSS later up the stack. The MSS is used to calculate the TCP window size and as that was abnormally large, it was calculating a zero window, even although the sockets receive buffer was completely empty." We rely on the Virtual I/O Server partition in a pseries environment to provide the MSS through the TCP header checksum field. The stipulation is that users should not disable checksum offloading if rx packet aggregation is enabled through VIOS. Some firmware offerings provide the MSS in the RX buffer. This is signalled by a bit in the RX queue descriptor. Reviewed-by:
Brian King <brking@linux.vnet.ibm.com> Reviewed-by:
Pradeep Satyanarayana <pradeeps@linux.vnet.ibm.com> Reviewed-by:
David Dai <zdai@us.ibm.com> Signed-off-by:
-
Florian Westphal authored
BugLink: https://bugs.launchpad.net/bugs/1640786 instead of allocating each xt_counter individually, allocate 4k chunks and then use these for counter allocation requests. This should speed up rule evaluation by increasing data locality, also speeds up ruleset loading because we reduce calls to the percpu allocator. As Eric points out we can't use PAGE_SIZE, page_allocator would fail on arches with 64k page size. Suggested-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Acked-by:
Pablo Neira Ayuso <pablo@netfilter.org> (backported from commit ae0ac0ed) Signed-off-by:
Eric Desrochers <eric.desrochers@canonical.com> Acked-by:
-
Florian Westphal authored
BugLink: https://bugs.launchpad.net/bugs/1640786 Keeps some noise away from a followup patch. Signed-off-by:
-
Florian Westphal authored
BugLink: https://bugs.launchpad.net/bugs/1640786 On SMP we overload the packet counter (unsigned long) to contain percpu offset. Hide this from callers and pass xt_counters address instead. Preparation patch to allocate the percpu counters in page-sized batch chunks. Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1655002Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1656876Signed-off-by:
-
Oliver O'Halloran authored
BugLink: http://bugs.launchpad.net/bugs/1656876 commit 90cae1fe upstream. As a part of memory initialisation the architecture passes an array to free_area_init_nodes() which specifies the max PFN of each memory zone. This array is not necessarily monotonic (due to unused zones) so this array is parsed to build monotonic lists of the min and max PFN for each zone. ZONE_MOVABLE is special cased here as its limits are managed by the mm subsystem rather than the architecture. Unfortunately, this special casing is broken when ZONE_MOVABLE is the not the last zone in the zone list. The core of the issue is: if (i == ZONE_MOVABLE) continue; arch_zone_lowest_possible_pfn[i] = arch_zone_highest_possible_pfn[i-1]; As ZONE_MOVABLE is skipped the lowest_possible_pfn of the next zone will be set to zero. This patch fixes this bug by adding explicitly tracking where the next zone should start rather than relying on the contents arch_zone_highest_possible_pfn[]. Thie is low priority. To get bitten by this you need to enable a zone that appears after ZONE_MOVABLE in the zone_type enum. As far as I can tell this means running a kernel with ZONE_DEVICE or ZONE_CMA enabled, so I can't see this affecting too many people. I only noticed this because I've been fiddling with ZONE_DEVICE on powerpc and 4.6 broke my test kernel. This bug, in conjunction with the changes in Taku Izumi's kernelcore=mirror patch (d91749c1) and powerpc being the odd architecture which initialises max_zone_pfn[] to ~0ul instead of 0 caused all of system memory to be placed into ZONE_DEVICE at boot, followed a panic since device memory cannot be used for kernel allocations. I've already submitted a patch to fix the powerpc specific bits, but I figured this should be fixed too. Link: http://lkml.kernel.org/r/1462435033-15601-1-git-send-email-oohall@gmail.comSigned-off-by:
Oliver O'Halloran <oohall@gmail.com> Cc: Anton Blanchard <anton@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Mel Gorman <mgorman@techsingularity.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Dennis Kadioglu authored
BugLink: http://bugs.launchpad.net/bugs/1656876 commit 2e40795c upstream. Plantronics BT600 does not support reading the sample rate which leads to many lines of "cannot get freq at ep 0x1" and "cannot get freq at ep 0x82". This patch adds the USB ID of the BT600 to quirks.c and avoids those error messages. Signed-off-by:
Dennis Kadioglu <denk@post.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Uwe Kleine-König authored
BugLink: http://bugs.launchpad.net/bugs/1656876 commit 7243e0b2 upstream. The calculation of SPR and SPPR doesn't round correctly at several places which might result in baud rates that are too big. For example with tclk_hz = 250000001 and target rate 25000000 it determined a divider of 10 which is wrong. Instead of fixing all the corner cases replace the calculation by an algorithm without a loop which should even be quicker to execute apart from being correct. Fixes: df59fa7f ("spi: orion: support armada extended baud rates") Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Tony Lindgren authored
BugLink: http://bugs.launchpad.net/bugs/1656876 commit cbf26428 upstream. We don't want to fall through to a bunch of errors for retention if PM_OMAP4_CPU_OSWR_DISABLE is not configured for a SoC. Fixes: 6099dd37 ("ARM: OMAP5 / DRA7: Enable CPU RET on suspend") Acked-by:
Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Kyle Roeschley authored
BugLink: http://bugs.launchpad.net/bugs/1656876 commit 7a3cc2a7 upstream. On Zynq, we haven't been reserving the correct amount of DMA-incapable RAM to keep DMA away from it (per the Zynq TRM Section 4.1, it should be the first 512k). In older kernels, this was masked by the memblock_reserve call in arm_memblock_init(). Now, reserve the correct amount excplicitly rather than relying on swapper_pg_dir, which is an address and not a size anyway. Fixes: 46f5b960 ("ARM: zynq: Reserve not DMAable space in front of the kernel") Signed-off-by:
Kyle Roeschley <kyle.roeschley@ni.com> Tested-by:
Nathan Rossi <nathan@nathanrossi.com> Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Larry Finger authored
BugLink: http://bugs.launchpad.net/bugs/1656876 commit 8ae679c4 upstream. I am getting the following warning when I build kernel 4.9-git on my PowerBook G4 with a 32-bit PPC processor: AS arch/powerpc/kernel/misc_32.o arch/powerpc/kernel/misc_32.S:299:7: warning: "CONFIG_FSL_BOOKE" is not defined [-Wundef] This problem is evident after commit 989cea5c ("kbuild: prevent lib-ksyms.o rebuilds"); however, this change in kbuild only exposes an error that has been in the code since 2005 when this source file was created. That was with commit 9994a338 ("powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S, systbl.S"). The offending line does not make a lot of sense. This error does not seem to cause any errors in the executable, thus I am not recommending that it be applied to any stable versions. Thanks to Nicholas Piggin for suggesting this solution. Fixes: 9994a338 ("powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S, systbl.S") Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by:
-
Takashi Sakamoto authored
BugLink: http://bugs.launchpad.net/bugs/1656876 commit 6a2a2f45 upstream. This module has a bug not to return error code in a case that data structure for transmitted packets fails to be initialized. This commit fixes the bug. Fixes: 35efa5c4 ("ALSA: firewire-tascam: add streaming functionality") Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1656876 commit 1ebb7114 upstream. Make sure we have enough of a report structure to validate before looking at it. Reported-by:
Benoit Camredon <benoit.camredon@airbus.com> Tested-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
David Ahern authored
BugLink: http://bugs.launchpad.net/bugs/1656876 [ Upstream commit 24c63bbc ] Frank reported that vrf devices can be created with a table id of 0. This breaks many of the run time table id checks and should not be allowed. Detect this condition at create time and fail with EINVAL. Fixes: 193125db ("net: Introduce VRF device driver") Reported-by:
Frank Kellermann <frank.kellermann@atos.net> Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
-
David Ahern authored
BugLink: http://bugs.launchpad.net/bugs/1656876 [ Upstream commit 7a18c5b9 ] fib_select_path does not call fib_select_multipath if oif is set in the flow struct. For VRF use cases oif is always set, so multipath route selection is bypassed. Use the FLOWI_FLAG_SKIP_NH_OIF to skip the oif check similar to what is done in fib_table_lookup. Add saddr and proto to the flow struct for the fib lookup done by the VRF driver to better match hash computation for a flow. Fixes: 613d09b3 ("net: Use VRF device index for lookups on TX") Signed-off-by:
-
Herbert Xu authored
BugLink: http://bugs.launchpad.net/bugs/1656876 [ Upstream commit 57ea52a8 ] The GRO fast path caches the frag0 address. This address becomes invalid if frag0 is modified by pskb_may_pull or its variants. So whenever that happens we must disable the frag0 optimization. This is usually done through the combination of gro_header_hard and gro_header_slow, however, the IPv6 extension header path did the pulling directly and would continue to use the GRO fast path incorrectly. This patch fixes it by disabling the fast path when we enter the IPv6 extension header path. Fixes: 78a478d0 ("gro: Inline skb_gro_header and cache frag0 virtual address") Reported-by:
Slava Shwartsman <slavash@mellanox.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1656876 [ Upstream commit 7cfd5fd5 ] On 32bit arches, (skb->end - skb->data) is not 'unsigned int', so we shall use min_t() instead of min() to avoid a compiler error. Fixes: 1272ce87 ("gro: Enter slow-path if there is no tailroom") Reported-by:
kernel test robot <fengguang.wu@intel.com> Signed-off-by:
-
Herbert Xu authored
BugLink: http://bugs.launchpad.net/bugs/1656876 [ Upstream commit 1272ce87 ] The GRO path has a fast-path where we avoid calling pskb_may_pull and pskb_expand by directly accessing frag0. However, this should only be done if we have enough tailroom in the skb as otherwise we'll have to expand it later anyway. This patch adds the check by capping frag0_len with the skb tailroom. Fixes: cb18978c ("gro: Open-code final pskb_may_pull") Reported-by:
-
hayeswang authored
BugLink: http://bugs.launchpad.net/bugs/1656876 [ Upstream commit 75dc692e ] Pause the rx and make sure the rx fifo is empty when the autosuspend occurs. If the rx data comes when the driver is canceling the rx urb, the host controller would stop getting the data from the device and continue it after next rx urb is submitted. That is, one continuing data is split into two different urb buffers. That let the driver take the data as a rx descriptor, and unexpected behavior happens. Signed-off-by:
Hayes Wang <hayeswang@realtek.com> Signed-off-by:
-
