- 20 Jan, 2017 40 commits
-
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1650059 On Hyper-V, performance critical channels use the monitor mechanism to signal the host when the guest posts mesages for the host. This mechanism minimizes the hypervisor intercepts and also makes the host more efficient in that each time the host is woken up, it processes a batch of messages as opposed to just one. The goal here is improve the throughput and this is at the expense of increased latency. Implement a mechanism to let the client driver decide if latency is important. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 3724287c) 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>
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1650059 The current delay between retries is unnecessarily high and is negatively affecting the time it takes to boot the system. Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1650059 For synthetic NIC channels, enable explicit signaling policy as netvsc wants to explicitly control when the host is to be signaled. Signed-off-by:
-
Dexuan Cui authored
BugLink: http://bugs.launchpad.net/bugs/1650059 There is a rare race when we remove an entry from the global list hv_context.percpu_list[cpu] in hv_process_channel_removal() -> percpu_channel_deq() -> list_del(): at this time, if vmbus_on_event() -> process_chn_event() -> pcpu_relid2channel() is trying to query the list, we can get the kernel fault. Similarly, we also have the issue in the code path: vmbus_process_offer() -> percpu_channel_enq(). We can resolve the issue by disabling the tasklet when updating the list. The patch also moves vmbus_release_relid() to a later place where the channel has been removed from the per-cpu and the global lists. Reported-by:
Rolf Neugebauer <rolf.neugebauer@docker.com> Signed-off-by:
Dexuan Cui <decui@microsoft.com> Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Background: userspace daemons registration protocol for Hyper-V utilities drivers has two steps: 1) daemon writes its own version to kernel 2) kernel reads it and replies with module version at this point we consider the handshake procedure being completed and we do hv_poll_channel() transitioning the utility device to HVUTIL_READY state. At this point we're ready to handle messages from kernel. When hvutil_transport is in HVUTIL_TRANSPORT_CHARDEV mode we have a single buffer for outgoing message. hvutil_transport_send() puts to this buffer and till the buffer is cleared with hvt_op_read() returns -EFAULT to all consequent calls. Host<->guest protocol guarantees there is no more than one request at a time and we will not get new requests till we reply to the previous one so this single message buffer is enough. Now to the race. When we finish negotiation procedure and send kernel module version to userspace with hvutil_transport_send() it goes into the above mentioned buffer and if the daemon is slow enough to read it from there we can get a collision when a request from the host comes, we won't be able to put anything to the buffer so the request will be lost. To solve the issue we need to know when the negotiation is really done (when the version message is read by the daemon) and transition to HVUTIL_READY state after this happens. Implement a callback on read to support this. Old style netlink communication is not affected by the change, we don't really know when these messages are delivered but we don't have a single message buffer there. Reported-by:
Barry Davis <barry_davis@stormagic.com> Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1650059 vmbus_teardown_gpadl() can result in infinite wait when it is called on 5 second timeout in vmbus_open(). The issue is caused by the fact that gpadl teardown operation won't ever succeed for an opened channel and the timeout isn't always enough. As a guest, we can always trust the host to respond to our request (and there is nothing we can do if it doesn't). Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1650059 In some cases create_gpadl_header() allocates submessages but we never free them. Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1650059 We use messagecount only once in vmbus_establish_gpadl() to check if it is safe to iterate through the submsglist. We can just initialize the list header in all cases in create_gpadl_header() instead. Signed-off-by:
-
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:
-
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:
-
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:
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:
-
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:
-
