- 08 Nov, 2016 29 commits
-
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit db685779 upstream. The pointer callbacks of ali5451 driver may return the value at the boundary occasionally, and it results in the kernel warning like snd_ali5451 0000:00:06.0: BUG: , pos = 16384, buffer size = 16384, period size = 1024 It seems that folding the position offset is enough for fixing the warning and no ill-effect has been seen by that. Reported-by:
Enrico Mioso <mrkiko.rs@gmail.com> Tested-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Seth Forshee <seth.forshee@canonical.com>
-
John Stultz authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 58bfea95 upstream. In commit 27727df2 ("Avoid taking lock in NMI path with CONFIG_DEBUG_TIMEKEEPING"), I changed the logic to open-code the timekeeping_get_ns() function, but I forgot to include the unit conversion from cycles to nanoseconds, breaking the function's output, which impacts users like perf. This results in bogus perf timestamps like: swapper 0 [000] 253.427536: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.426573: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.426687: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.426800: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.426905: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427022: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427127: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427239: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427346: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427463: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 255.426572: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) Instead of more reasonable expected timestamps like: swapper 0 [000] 39.953768: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.064839: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.175956: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.287103: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.398217: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.509324: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.620437: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.731546: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.842654: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.953772: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 41.064881: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) Add the proper use of timekeeping_delta_to_ns() to convert the cycle delta to nanoseconds as needed. Thanks to Brendan and Alexei for finding this quickly after the v4.8 release. Unfortunately the problematic commit has landed in some -stable trees so they'll need this fix as well. Many apologies for this mistake. I'll be looking to add a perf-clock sanity test to the kselftest timers tests soon. Fixes: 27727df2 "timekeeping: Avoid taking lock in NMI path with CONFIG_DEBUG_TIMEKEEPING" Reported-by:
Brendan Gregg <bgregg@netflix.com> Reported-by:
Alexei Starovoitov <alexei.starovoitov@gmail.com> Tested-and-reviewed-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by:
John Stultz <john.stultz@linaro.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Link: http://lkml.kernel.org/r/1475636148-26539-1-git-send-email-john.stultz@linaro.orgSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by:
-
Colin Ian King authored
BugLink: http://bugs.launchpad.net/bugs/1633506 Enable module build of the Firmware Test Suite EFI test driver Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
Colin Ian King authored
BugLink: http://bugs.launchpad.net/bugs/1633506 This driver is used by the Firmware Test Suite (FWTS) for testing the UEFI runtime interfaces readiness of the firmware. This driver exports UEFI runtime service interfaces into userspace, which allows to use and test UEFI runtime services provided by the firmware. This driver uses the efi.<service> function pointers directly instead of going through the efivar API to allow for direct testing of the UEFI runtime service interfaces provided by the firmware. Details for FWTS are available from, <https://wiki.ubuntu.com/FirmwareTestSuite> Signed-off-by:
Ivan Hu <ivan.hu@canonical.com> Cc: joeyli <jlee@suse.com> Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk> (backport from upstream commit ff6301da) Signed-off-by:
-
Masaki Ota authored
Issue reproduction procedure: 1. three or more fingers put on Touchpad. 2. release fingers from Touchpad. 3. move the cursor by one finger. 4. the cursor does not move. Cause: We do not notify multi fingers state correctly to input subsystem. For example, when three fingers release from Touchpad, fingers state is 3 -> 0. It needs to notify first, second and third finger's releasing state. Fix this by not breaking out on z axis and move x,y,z input handling code to the correct place so that it's in fact per-finger. BugLink: https://bugs.launchpad.net/bugs/1633321 [jkosina@suse.cz: reword changelog] Signed-off-by:
Masaki Ota <masaki.ota@jp.alps.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> (cherry picked from commit 9a54cf46) Signed-off-by:
Ying-Chun Liu (PaulLiu) <paul.liu@canonical.com> Acked-by:
-
Craig Magina authored
BugLink: https://launchpad.net/bugs/1632739Signed-off-by:
Craig Magina <craig.magina@canonical.com> Acked-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 Added path to the MDIO driver and Documentation file. Signed-off-by:
Iyappan Subramanian <isubramanian@apm.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 2efccc60 yakkety) Signed-off-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 Added mdio node for mdio driver. Also added phy-handle reference to the ethernet nodes. Removed unused clock node from storm sgenet1. Signed-off-by:
Fushen Chen <fchen@apm.com> Tested-by:
Toan Le <toanle@apm.com> Signed-off-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 Changed SGMII 1G get_settings to use phy_ethtool_gset. Changed SGMII 1G set_settings to use phy_ethtool_sset. Signed-off-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 This patch reuses the mdio read/write and phy_register functions and removed the local definitions. Signed-off-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 This patch enables MDIO driver by, - Selecting MDIO_XGENE - Changed open and close to use phy_start and phy_stop - Changed to use mac_ops->tx(rx)_enable and tx(rx)_disable Signed-off-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 This patch adds xgene_enet_check_phy_hanlde() function that checks whether MDIO driver is probed successfully and sets pdata->mdio_driver to true. If MDIO driver is not probed, ethernet driver falls back to backward compatibility mode. Since enum xgene_enet_cmd is used by MDIO driver, removing this from ethernet driver. Signed-off-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 Currently, SGMII based 1G rely on the hardware registers for link state and sometimes it's not reliable. To get most accurate link state, this interface has to use the MDIO bus to poll the PHY. In X-Gene SoC, MDIO bus is shared across RGMII and SGMII based 1G interfaces, so adding this driver to manage MDIO bus. This driver registers the mdio bus and registers the PHYs connected to it. Signed-off-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 This patch fixes clock reset sequence. - Added clock reset sequence for ACPI - Added delay in clock reset sequence to make sure pulse is generated - Added clk_unprepare_disable() in port shutdown to make sure clock increment/decrement counts are matching - Removed MII_MGMT_CONFIG programming, since it is not required - Fixed programming XGENET_CONFIG_REG to enable SGMII mode Signed-off-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 When the driver is configured as kernel module and when it gets unloaded and reloaded, kernel crash was observed. This patch addresses the software cleanup by doing the following, - Moved register_netdev call after hardware is ready - Since ndev is not ready, added set_irq_name to set irq name - Since ndev is not ready, changed mdio_bus->parent to pdev->dev - Replaced netif_start(stop)_queue by netif_tx_start(stop)_queues - Removed napi_del call since it's called by free_netdev - Added dev_close call, within remove - Added shutdown callback - Changed to use dmam_ APIs Signed-off-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 When the driver is configured as kernel module and when it gets unloaded and reloaded, kernel crash was observed. This patch address the hardware resource cleanups by doing the following, - Added mac_ops->clear() to do prefetch buffer clean up - Fixed delete freepool buffers logic - Reordered mac_enable and mac_disable - Added Tx completion ring free - Moved down delete_desc_rings after ring cleanup Signed-off-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 Since mac_init is too heavy to be called when the link changes, moved the speed_set configuration to a new function and added mac_ops->set_speed function pointer. This function will be called from adjust_link callback. Added cases for 10/100 support for SGMII based 1G interface. Signed-off-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 This patch fixes SG_RX_DV_GATE_REG_0_ADDR register offset and ring state field lengths. Signed-off-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 This patch fixes the race condition on updating the statistics counters by moving the counters to the ring structure. Signed-off-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 This patch addresses ununiform latency across queues by adding more queues to match with, upto number of CPU cores. Also, number of interrupts are increased and the channel numbers are reordered. Signed-off-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 Since hardware doesn't allow sharing of interrupts, this patch fixes the same by removing IRQF_SHARED flag. Signed-off-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 This patch fixes the crash observed during IPv4 forward test by setting the drop field in the dbptr. Signed-off-by:
-
Matthias Brugger authored
BugLink: https://launchpad.net/bugs/1632739 When probe bails out with an error, we try to unregister the netdev before we have even registered it. Fix the goto statements for that. Signed-off-by:
Matthias Brugger <mbrugger@suse.com> Signed-off-by:
-
Julia Lawall authored
BugLink: https://launchpad.net/bugs/1632739 The xgene_cle_ops structure is never modified, so declare it as const. Done with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Acked-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 This patch gets ethernet to CPU channel (prefetch buffer number) from the newly added 'channel' property, thus decoupling Linux driver from resource management. Signed-off-by:
-
Sergei Shtylyov authored
BugLink: https://launchpad.net/bugs/1632739 Now that get_phy_device() no longer returns NULL on error, we don't need to check for it... Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Saurabh Sengar authored
BugLink: https://launchpad.net/bugs/1632739 this patch does the following: 1 . remove unnecessary if, else condition 2 . reduce one variable 3 . change the return type of 2 functions to void as there return values turn out to be 0 always after above changes Signed-off-by:
Saurabh Sengar <saurabh.truth@gmail.com> Signed-off-by:
-
Raanan Avargil authored
BugLinks: http://bugs.launchpad.net/bugs/1632578 i219 (4) and i219 (5) are the next LOM generations that will be available on the next Intel platform (KabeLake). This patch provides the initial support for the devices. Signed-off-by:
Raanan Avargil <raanan.avargil@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry picked from commit 9cd34b3a) Signed-off-by:
Phidias Chiang <phidias.chiang@canonical.com> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com>
-
Luis Henriques authored
Ignore: yes Signed-off-by:Luis Henriques <luis.henriques@canonical.com>
-
- 26 Oct, 2016 7 commits
-
-
Kamal Mostafa authored
Signed-off-by:Kamal Mostafa <kamal@canonical.com>
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1635721Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com>
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1635721 This is a driver for the ENA family of networking devices. Signed-off-by:
Netanel Belgazal <netanel@annapurnalabs.com> Signed-off-by:
-
David Decotigny authored
BugLink: http://bugs.launchpad.net/bugs/1635721 This patch defines a new ETHTOOL_GLINKSETTINGS/SLINKSETTINGS API, handled by the new get_link_ksettings/set_link_ksettings callbacks. This API provides support for most legacy ethtool_cmd fields, adds support for larger link mode masks (up to 4064 bits, variable length), and removes ethtool_cmd deprecated fields (transceiver/maxrxpkt/maxtxpkt). This API is deprecating the legacy ETHTOOL_GSET/SSET API and provides the following backward compatibility properties: - legacy ethtool with legacy drivers: no change, still using the get_settings/set_settings callbacks. - legacy ethtool with new get/set_link_ksettings drivers: the new driver callbacks are used, data internally converted to legacy ethtool_cmd. ETHTOOL_GSET will return only the 1st 32b of each link mode mask. ETHTOOL_SSET will fail if user tries to set the ethtool_cmd deprecated fields to non-0 (transceiver/maxrxpkt/maxtxpkt). A kernel warning is logged if driver sets higher bits. - future ethtool with legacy drivers: no change, still using the get_settings/set_settings callbacks, internally converted to new data structure. Deprecated fields (transceiver/maxrxpkt/maxtxpkt) will be ignored and seen as 0 from user space. Note that that "future" ethtool tool will not allow changes to these deprecated fields. - future ethtool with new drivers: direct call to the new callbacks. By "future" ethtool, what is meant is: - query: first try ETHTOOL_GLINKSETTINGS, and revert to ETHTOOL_GSET if fails - set: query first and remember which of ETHTOOL_GLINKSETTINGS or ETHTOOL_GSET was successful + if ETHTOOL_GLINKSETTINGS was successful, then change config with ETHTOOL_SLINKSETTINGS. A failure there is final (do not try ETHTOOL_SSET). + otherwise ETHTOOL_GSET was successful, change config with ETHTOOL_SSET. A failure there is final (do not try ETHTOOL_SLINKSETTINGS). The interaction user/kernel via the new API requires a small ETHTOOL_GLINKSETTINGS handshake first to agree on the length of the link mode bitmaps. If kernel doesn't agree with user, it returns the bitmap length it is expecting from user as a negative length (and cmd field is 0). When kernel and user agree, kernel returns valid info in all fields (ie. link mode length > 0 and cmd is ETHTOOL_GLINKSETTINGS). Data structure crossing user/kernel boundary is 32/64-bit agnostic. Converted internally to a legal kernel bitmap. The internal __ethtool_get_settings kernel helper will gradually be replaced by __ethtool_get_link_ksettings by the time the first "link_settings" drivers start to appear. So this patch doesn't change it, it will be removed before it needs to be changed. Signed-off-by:
David Decotigny <decot@googlers.com> Signed-off-by:
-
David Decotigny authored
BugLink: http://bugs.launchpad.net/bugs/1635721 Aimed at transferring bitmaps to/from user-space in a 32/64-bit agnostic way. Tested: unit tests (next patch) on qemu i386, x86_64, ppc, ppc64 BE and LE, ARM. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Andy Whitcroft authored
There is some issue with squashfs decoding when done in a multi-threaded manner which leads to large memory consumption. Either we have a leak or more probabally we have pathalogical case leading to horrible internal fragmentation. For the moment turn it off while it can be investigated. BugLink: http://bugs.launchpad.net/bugs/1636847Signed-off-by:
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 20 Oct, 2016 4 commits
-
-
Seth Forshee authored
Signed-off-by: -
Colin Ian King authored
UBUNTU: SAUCE: KEYS: ensure xbuf is large enough to fix buffer overflow in proc_keys_show (LP: #1634496) BugLink: http://bugs.launchpad.net/bugs/1634496 CVE-2016-7042 When stack protect is enabled xbuf is too small for timeout data causing a buffer overflow and a stack protector corruption report. OriginalAuthor: Vladis Dronov <vdronov@redhat.com> OriginalLocation: https://bugzilla.redhat.com/attachment.cgi?id=1200212&action=diffSigned-off-by:
-
Paul Mackerras authored
BugLink: http://bugs.launchpad.net/bugs/1632462 Debugging a data corruption issue with virtio-net/vhost-net led to the observation that __copy_tofrom_user was occasionally returning a value 16 larger than it should. Since the return value from __copy_tofrom_user is the number of bytes not copied, this means that __copy_tofrom_user can occasionally return a value larger than the number of bytes it was asked to copy. In turn this can cause higher-level copy functions such as copy_page_to_iter_iovec to corrupt memory by copying data into the wrong memory locations. It turns out that the failing case involves a fault on the store at label 79, and at that point the first unmodified byte of the destination is at R3 + 16. Consequently the exception handler for that store needs to add 16 to R3 before using it to work out how many bytes were not copied, but in this one case it was not adding the offset to R3. To fix it, this moves the label 179 to the point where we add 16 to R3. I have checked manually all the exception handlers for the loads and stores in this code and the rest of them are correct (it would be excellent to have an automated test of all the exception cases). Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
Leann Ogasawara <leann.ogasawara@canonical.com> Acked-by:
-
Laurent Dufour authored
BugLink: http://bugs.launchpad.net/bugs/1628976 https://patchwork.kernel.org/patch/9364805/ This commit fixes a stack corruption in the pseries specific code dealing with the huge pages. In __pSeries_lpar_hugepage_invalidate() the buffer used to pass arguments to the hypervisor is not large enough. This leads to a stack corruption where a previously saved register could be corrupted leading to unexpected result in the caller, like the following panic: Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2048 NUMA pSeries Modules linked in: virtio_balloon ip_tables x_tables autofs4 virtio_blk 8139too virtio_pci virtio_ring 8139cp virtio CPU: 11 PID: 1916 Comm: mmstress Not tainted 4.8.0 #76 task: c000000005394880 task.stack: c000000005570000 NIP: c00000000027bf6c LR: c00000000027bf64 CTR: 0000000000000000 REGS: c000000005573820 TRAP: 0300 Not tainted (4.8.0) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 84822884 XER: 20000000 CFAR: c00000000010a924 DAR: 420000000014e5e0 DSISR: 40000000 SOFTE: 1 GPR00: c00000000027bf64 c000000005573aa0 c000000000e02800 c000000004447964 GPR04: c00000000404de18 c000000004d38810 00000000042100f5 00000000f5002104 GPR08: e0000000f5002104 0000000000000001 042100f5000000e0 00000000042100f5 GPR12: 0000000000002200 c00000000fe02c00 c00000000404de18 0000000000000000 GPR16: c1ffffffffffe7ff 00003fff62000000 420000000014e5e0 00003fff63000000 GPR20: 0008000000000000 c0000000f7014800 0405e600000000e0 0000000000010000 GPR24: c000000004d38810 c000000004447c10 c00000000404de18 c000000004447964 GPR28: c000000005573b10 c000000004d38810 00003fff62000000 420000000014e5e0 NIP [c00000000027bf6c] zap_huge_pmd+0x4c/0x470 LR [c00000000027bf64] zap_huge_pmd+0x44/0x470 Call Trace: [c000000005573aa0] [c00000000027bf64] zap_huge_pmd+0x44/0x470 (unreliable) [c000000005573af0] [c00000000022bbd8] unmap_page_range+0xcf8/0xed0 [c000000005573c30] [c00000000022c2d4] unmap_vmas+0x84/0x120 [c000000005573c80] [c000000000235448] unmap_region+0xd8/0x1b0 [c000000005573d80] [c0000000002378f0] do_munmap+0x2d0/0x4c0 [c000000005573df0] [c000000000237be4] SyS_munmap+0x64/0xb0 [c000000005573e30] [c000000000009560] system_call+0x38/0x108 Instruction dump: fbe1fff8 fb81ffe0 7c7f1b78 7ca32b78 7cbd2b78 f8010010 7c9a2378 f821ffb1 7cde3378 4bfffea9 7c7b1b79 41820298 <e87f0000> 48000130 7fa5eb78 7fc4f378 Most of the time, the bug is surfacing in a caller up in the stack from __pSeries_lpar_hugepage_invalidate() which is quite confusing. This bug is pending since v3.11 but was hidden if a caller of the caller of __pSeries_lpar_hugepage_invalidate() has pushed the corruped register (r18 in this case) in the stack and is not using it until restoring it. GCC 6.2.0 seems to raise it more frequently. This commit also change the definition of the parameter buffer in pSeries_lpar_flush_hash_range() to rely on the global define PLPAR_HCALL9_BUFSIZE (no functional change here). Fixes: 1a527286 ("powerpc: Optimize hugepage invalidate") Cc: <stable@vger.kernel.org> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
Laurent Dufour <ldufour@linux.vnet.ibm.com> Reviewed-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Acked-by:
Balbir Singh <bsingharora@gmail.com> Signed-off-by:
-
