- 16 Nov, 2017 40 commits
-
-
Valentin Longchamp authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit a674c7d4 ] It is not implemented on the kmcoge4 hardware and if not disabled it leads to error messages with the corenet32_smp_defconfig. Signed-off-by:
Valentin Longchamp <valentin.longchamp@keymile.com> Signed-off-by:
Scott Wood <oss@buserror.net> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Nate Watterson authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 810871c5 ] To prevent corruption of the stage-1 context pointer field when updating STEs, rebuild the entire containing dword instead of clearing individual fields. Signed-off-by:
Nate Watterson <nwatters@codeaurora.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Li Zhong authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 37451bc9 ] Some counters are added in Commit 6e0365b7 ("KVM: PPC: Book3S HV: Add ICP real mode counters"), to provide some performance statistics to determine whether further optimizing is needed for real mode functions. The n_reject counter counts how many times ICP rejects an irq because of priority in real mode. The redelivery of an lsi that is still asserted after eoi doesn't fall into this category, so the increasement there is removed. Also, it needs to be increased in icp_rm_deliver_irq() if it rejects another one. Signed-off-by:
Li Zhong <zhong@linux.vnet.ibm.com> Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
-
Noralf Trønnes authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit a67834f8 ] Call drm_debugfs_cleanup() in case drm_debugfs_init() fails to cover for failure in the drm_driver.debugfs_init callback. Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-3-noralf@tronnes.orgSigned-off-by:
-
Juergen Gross authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 56dd5af9 ] The default for the maximum number of tx/rx queues of one interface is the number of cpus of the system today. As each queue pair reserves 512 grant pages this default consumes a ridiculous number of grants for large guests. Limit the queue number to 8 as default. This value can be modified via a module parameter if required. Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit d9bf28e2 ] The PCI core will write to the bridge window config multiple times while they are enabled. This can lead to mbus failures like this: mvebu_mbus: cannot add window '4:e8', conflicts with another window mvebu-pcie mbus:pex@e0000000: Could not create MBus window at [mem 0xe0000000-0xe00fffff]: -22 For me this is happening during a hotplug cycle. The PCI core is not changing the values, just writing them twice while active. The patch addresses the general case of any change to an active window, but not atomically. The code is slightly refactored so io and mem can share more of the window logic. Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Maciej W. Rozycki authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 879e5a0d ] Fix: WARNING: drivers/video/fbdev/pmag-ba-fb.o(.text+0x308): Section mismatch in reference from the function pmagbafb_probe() to the function .init.text:pmagbafb_erase_cursor() The function pmagbafb_probe() references the function __init pmagbafb_erase_cursor(). This is often because pmagbafb_probe lacks a __init annotation or the annotation of pmagbafb_erase_cursor is wrong. -- a fallout from a missed update from commit 9625b513 ("VIDEO: PMAG-BA: Fix section mismatch") and then commit 48c68c4f ("Drivers: video: remove __dev* attributes.") Signed-off-by:
Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Lars-Peter Clausen authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit da8892d4 ] The adv7604 driver platform data contains fields for configuring the drive strength of the output pins. When probing the driver through DT these fields are not explicitly initialized, which means they are left at 0. This is a reserved setting for the drive strength configuration though and can cause signal integrity issues. Whether these signal integrity issues are visible depends on the PCB specifics (e.g. the higher the load capacitance for the output the more visible the issue). But it has been observed on existing solutions at high pixel clock rates. Initialize the drive strength settings to the power-on-reset value of the device when probing through devicetree to avoid this issue. Fixes: 0e158be0162b ("adv7604: Add DT support") Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1731915Signed-off-by:
-
Larry Finger authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 07222e53 ] Sparse reports the following: CHECK drivers/staging/rtl8712/rtl871x_xmit.c drivers/staging/rtl8712/rtl871x_xmit.c:350:44: warning: restricted __le32 degrades to integer drivers/staging/rtl8712/rtl871x_xmit.c:491:23: warning: incorrect type in initializer (different base types) drivers/staging/rtl8712/rtl871x_xmit.c:491:23: expected unsigned short [usertype] *fctrl drivers/staging/rtl8712/rtl871x_xmit.c:491:23: got restricted __le16 *<noident> drivers/staging/rtl8712/rtl871x_xmit.c:580:36: warning: incorrect type in assignment (different base types) drivers/staging/rtl8712/rtl871x_xmit.c:580:36: expected unsigned short [unsigned] [short] [usertype] <noident> drivers/staging/rtl8712/rtl871x_xmit.c:580:36: got restricted __be16 [usertype] <noident> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Juergen Gross authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 4e93b648 ] When registering for the Xenstore watch of the node control/sysrq the handler will be called at once. Don't issue an error message if the Xenstore node isn't there, as it will be created only when an event is being triggered. Signed-off-by:
-
Sudip Mukherjee authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 6792eb0c ] If dvb_attach() fails then we were just printing an error message and exiting but the memory allocated to state was not released. Signed-off-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by:
-
Stefan Haberland authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 2202134e ] Check if the device pointer is valid. Just a sanity check since we already are in the int handler of the device. Signed-off-by:
Stefan Haberland <sth@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Alexander Usyskin authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 7c47d2ca ] Request for a notification from a disconnected client will be ignored silently by the FW but the caller should know that the operation hasn't succeeded. Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Arvind Yadav authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 4742575c ] Free memory mapping, if fimc_is_probe is not successful. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Alexander Boyko authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 4c43c27d ] This patch resolves IO vs eviction race. After eviction failed export stayed at stale list, a client had IO processing and reconnected during it. A client sent brw rpc with last lock cookie and new connection. The lock with failed export was found and assert was happened. (ost_handler.c:1812:ost_prolong_lock_one()) ASSERTION( lock->l_export == opd->opd_exp ) failed: 1. Skip the lock at ldlm_handle2lock if lock export failed. 2. Validation of lock for IO was added at hpreq_check(). The lock searching is based on granted interval tree. If server doesn`t have a valid lock, it reply to client with ESTALE. Signed-off-by:
Alexander Boyko <alexander.boyko@seagate.com> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7702 Seagate-bug-id: MRP-2787 Reviewed-on: http://review.whamcloud.com/18120Reviewed-by:
Fan Yong <fan.yong@intel.com> Reviewed-by:
Vitaly Fertman <vitaly.fertman@seagate.com> Reviewed-by:
Oleg Drokin <oleg.drokin@intel.com> Signed-off-by:
James Simmons <jsimmons@infradead.org> Signed-off-by:
-
frank zago authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 22aadb91 ] The function hai_dump_data_field will do a stack buffer overrun when cat'ing /sys/fs/lustre/.../hsm/actions if an action has some data in it. hai_dump_data_field uses snprintf. But there is no check for truncation, and the value returned by snprintf is used as-is. The coordinator code calls hai_dump_data_field with 12 bytes in the buffer. The 6th byte of data is printed incompletely to make room for the terminating NUL. However snprintf still returns 2, so when hai_dump_data_field writes the final NUL, it does it outside the reserved buffer, in the 13th byte of the buffer. This stack buffer overrun hangs my VM. Fix by checking that there is enough room for the next 2 characters plus the NUL terminator. Don't print half bytes. Change the format to 02X instead of .2X, which makes more sense. Signed-off-by:
frank zago <fzago@cray.com> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8171 Reviewed-on: http://review.whamcloud.com/20338Reviewed-by:
John L. Hammond <john.hammond@intel.com> Reviewed-by:
Jean-Baptiste Riaux <riaux.jb@intel.com> Reviewed-by:
-
Yang Sheng authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 77759771 ] The function generic_file_read_iter() does not check EOF before invoke direct_IO callback. So we have to check it ourselves. Signed-off-by:
Yang Sheng <yang.sheng@intel.com> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8969 Reviewed-on: https://review.whamcloud.com/24552Reviewed-by:
Bob Glossman <bob.glossman@intel.com> Reviewed-by:
Bobi Jam <bobijam@hotmail.com> Reviewed-by:
-
Javier Martinez Canillas authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit a93151a7 ] If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo drivers/platform/x86/intel_mid_thermal.ko | grep alias $ After this patch: $ modinfo drivers/platform/x86/intel_mid_thermal.ko | grep alias alias: platform:msic_thermal Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Raghava Aditya Renukunta authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 4ec57fb4 ] Make sure that the driver processes error conditions even in the fast response path for response from the adapter. Signed-off-by:
Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Signed-off-by:
Dave Carroll <David.Carroll@microsemi.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Jan Beulich authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 4fed1b12 ] A negative return value indicates an error; in fact the function at present won't ever return zero. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Reviewed-by:
-
Oleh Kravchenko authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 6c5da803 ] Internal Master 3 Bus can send and receive only 4 bytes per time. Signed-off-by:
Oleh Kravchenko <oleg@kaa.org.ua> Signed-off-by:
-
Taeung Song authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 75fc5ae5 ] Signed-off-by:
Taeung Song <treeze.taeung@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/1485952447-7013-2-git-send-email-treeze.taeung@gmail.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Rex Zhu authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 28ed5504 ] Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Chris Brandt authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 71ccea09 ] This fixes the condition where the controller has not fully completed its final transfer and leaves the bus and controller in a undesirable state. At the end of the last transmitted byte, the existing driver would just signal for a STOP condition to be transmitted then immediately signal completion. However, the full STOP procedure might not have fully taken place by the time the runtime PM shuts off the peripheral clock, leaving the bus in a suspended state. Alternatively, the STOP condition on the bus may have completed, but when the next transaction is requested by the upper layer, not all the necessary register cleanup was finished from the last transfer which made the driver return BUS BUSY when it really wasn't. This patch now makes all transmit and receive transactions wait for the STOP condition to fully complete before signaling a completed transaction. With this new method, runtime PM no longer seems to be an issue. Fixes: 310c18a4 ("i2c: riic: add driver") Signed-off-by:
Chris Brandt <chris.brandt@renesas.com> Reviewed-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Jan Kara authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 5469d7c3 ] Avoid using stripe_width for sbi->s_stripe value if it is not actually set. It prevents using the stride for sbi->s_stripe. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Jan Kara authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit d9b22cf9 ] When a filesystem is created using: mkfs.ext4 -b 4096 -E stride=512 <dev> and we try to allocate 64MB extent, we will end up directly in ext4_mb_complex_scan_group(). This is because the request is detected as power-of-two allocation (so we start in ext4_mb_regular_allocator() with ac_criteria == 0) however the check before ext4_mb_simple_scan_group() refuses the direct buddy scan because the allocation request is too large. Since cr == 0, the check whether we should use ext4_mb_scan_aligned() fails as well and we fall back to ext4_mb_complex_scan_group(). Fix the problem by checking for upper limit on power-of-two requests directly when detecting them. Reported-by:
Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by:
-
Larry Finger authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 221c46d2 ] The headers describing a number of network packets do not have the correct endian settings for several types of data. Signed-off-by:
-
Hans de Goede authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 1af468eb ] The R in PEK_DBR stands for rising, so it should be mapped to AXP288_IRQ_POKP where the last P stands for positive edge. Likewise PEK_DBF should be mapped to the falling edge, aka the _N_egative edge, so it should be mapped to AXP288_IRQ_POKN. This fixes the inverted powerbutton status reporting by the axp20x-pek driver. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Linus Walleij authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 7e9c40c6 ] In the current boot, clients making use of the AB8500 sysctrl may be probed before the ab8500-sysctrl driver. This gives them -EINVAL, but should rather give -EPROBE_DEFER. Before this, the abx500 clock driver didn't probe properly, and as a result the codec driver in turn using the clocks did not probe properly. After this patch, everything probes properly. Also add OF compatible-string probing. This driver is all device tree, so let's just make a drive-by-fix of that as well. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Ulf Hansson authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 40d727a2 ] Some of the pxa platforms, balloon3, colibri-pxa270-income, corgi, trizeps4, vpac270, zeus and zylonite depends on leds.h. Explicitly include it instead of relying on the public mmc header host.h. Cc: Daniel Mack <daniel@zonque.org> Cc: Haojian Zhuang <haojian.zhuang@gmail.com> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Cc: <linux-arm-kernel@lists.infradead.org> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Acked-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit e1c6ec26 ] I got this new build error on today's linux-next drivers/mmc/host/s3cmci.h:69:24: error: field 'pio_tasklet' has incomplete type struct tasklet_struct pio_tasklet; drivers/mmc/host/s3cmci.c: In function 's3cmci_enable_irq': drivers/mmc/host/s3cmci.c:390:4: error: implicit declaration of function 'enable_irq';did you mean 'enable_imask'? [-Werror=implicit-function-declaration] While I haven't found out why this happened now and not earlier, the solution is obvious, we should include the header that defines the structure. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Grygorii Strashko authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 09bb6e93 ] There are two reasons for reporting wakeup event when dedicated wakeup IRQ is triggered: - wakeup events accounting, so proper statistical data will be displayed in sysfs and debugfs; - there are small window when System is entering suspend during which dedicated wakeup IRQ can be lost: dpm_suspend_noirq() |- device_wakeup_arm_wake_irqs() |- dev_pm_arm_wake_irq(X) |- IRQ is enabled and marked as wakeup source [1]... |- suspend_device_irqs() |- suspend_device_irq(X) |- irqd_set(X, IRQD_WAKEUP_ARMED); |- wakup IRQ armed The wakeup IRQ can be lost if it's triggered at point [1] and not armed yet. Hence, fix above cases by adding simple pm_wakeup_event() call in handle_threaded_wake_irq(). Fixes: 4990d4fe (PM / Wakeirq: Add automated device wake IRQ handling) Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Tested-by:
Keerthy <j-keerthy@ti.com> [ tony@atomide.com: added missing return to avoid warnings ] Tested-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Linus Torvalds authored
BugLink: http://bugs.launchpad.net/bugs/1731915 commit a0cb2b5c upstream. Commit 6575257c ("tracing/samples: Fix creation and deletion of simple_thread_fn creation") introduced a new warning due to using a boolean as a counter. Just make it "int". Fixes: 6575257c ("tracing/samples: Fix creation and deletion of simple_thread_fn creation") Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Steven Rostedt (VMware) authored
BugLink: http://bugs.launchpad.net/bugs/1731915 commit 6575257c upstream. Commit 7496946a ("tracing: Add samples of DECLARE_EVENT_CLASS() and DEFINE_EVENT()") added template examples for all the events. It created a DEFINE_EVENT_FN() example which reused the foo_bar_reg and foo_bar_unreg functions. Enabling both the TRACE_EVENT_FN() and DEFINE_EVENT_FN() example trace events caused the foo_bar_reg to be called twice, creating the test thread twice. The foo_bar_unreg would remove it only once, even if it was called multiple times, leaving a thread existing when the module is unloaded, causing an oops. Add a ref count and allow foo_bar_reg() and foo_bar_unreg() be called by multiple trace events. Fixes: 7496946a ("tracing: Add samples of DECLARE_EVENT_CLASS() and DEFINE_EVENT()") Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1731915 commit 65e93108 upstream. We recently added an integer overflow check but it needs an additional tweak to work properly on 32 bit systems. The problem is that we're doing the right hand side of the assignment as type unsigned long so the max it will have an integer overflow instead of being larger than SIZE_MAX. That means the "sz > SIZE_MAX" condition is never true even on 32 bit systems. We need to first cast it to u64 and then do the math. Fixes: 4a630fad ("drm/msm: Fix potential buffer overflow issue") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@gmail.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Kasin Li authored
BugLink: http://bugs.launchpad.net/bugs/1731915 commit 4a630fad upstream. In function submit_create, if nr_cmds or nr_bos is assigned with negative value, the allocated buffer may be small than intended. Using this buffer will lead to buffer overflow issue. Signed-off-by:
Kasin Li <donglil@codeaurora.org> Signed-off-by:
-
Namhyung Kim authored
BugLink: http://bugs.launchpad.net/bugs/1731915 commit b581c01f upstream. On my Archlinux machine, perf faild to build like below: CC scripts/perl/Perf-Trace-Util/Context.o In file included from /usr/lib/perl5/core/perl/CORE/perl.h:3905:0, from Context.xs:23: /usr/lib/perl5/core/perl/CORE/inline.h: In function : /usr/lib/perl5/core/perl/CORE/cop.h:612:13: warning: declaration of 'av' shadows a previous local [-Werror-shadow] AV *av =3D GvAV(PL_defgv); ^ /usr/lib/perl5/core/perl/CORE/inline.h:526:5: note: in expansion of macro 'CX_POP_SAVEARRAY' CX_POP_SAVEARRAY(cx); ^~~~~~~~~~~~~~~~ In file included from /usr/lib/perl5/core/perl/CORE/perl.h:5853:0, from Context.xs:23: /usr/lib/perl5/core/perl/CORE/inline.h:518:9: note: shadowed declaration is here AV *av; ^~ What I did to fix is adding '-Wno-shadow' as the error message said it's the cause of the failure. Since it's from the perl (not perf) code base, we don't have the control so I just wanted to ignore the warning when compiling perl scripting code. Committer note: This also fixes the build on Fedora Rawhide. Signed-off-by:
Namhyung Kim <namhyung@kernel.org> Tested-by:
-
Ashish Samant authored
BugLink: http://bugs.launchpad.net/bugs/1731915 commit 105ddc93 upstream. The first cluster group descriptor is not stored at the start of the group but at an offset from the start. We need to take this into account while doing fstrim on the first cluster group. Otherwise we will wrongly start fstrim a few blocks after the desired start block and the range can cross over into the next cluster group and zero out the group descriptor there. This can cause filesytem corruption that cannot be fixed by fsck. Link: http://lkml.kernel.org/r/1507835579-7308-1-git-send-email-ashish.samant@oracle.comSigned-off-by:
Ashish Samant <ashish.samant@oracle.com> Reviewed-by:
Junxiao Bi <junxiao.bi@oracle.com> Reviewed-by:
Joseph Qi <jiangqi903@gmail.com> Cc: Mark Fasheh <mfasheh@versity.com> Cc: Joel Becker <jlbec@evilplan.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1731915 commit 1cce91df upstream. The asm-generic/unaligned.h header provides two different implementations for accessing unaligned variables: the access_ok.h version used when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set pretends that all pointers are in fact aligned, while the le_struct.h version convinces gcc that the alignment of a pointer is '1', to make it issue the correct load/store instructions depending on the architecture flags. On ARMv5 and older, we always use the second version, to let the compiler use byte accesses. On ARMv6 and newer, we currently use the access_ok.h version, so the compiler can use any instruction including stm/ldm and ldrd/strd that will cause an alignment trap. This trap can significantly impact performance when we have to do a lot of fixups and, worse, has led to crashes in the LZ4 decompressor code that does not have a trap handler. This adds an ARM specific version of asm/unaligned.h that uses the le_struct.h/be_struct.h implementation unconditionally. This should lead to essentially the same code on ARMv6+ as before, with the exception of using regular load/store instructions instead of the trapping instructions multi-register variants. The crash in the LZ4 decompressor code was probably introduced by the patch replacing the LZ4 implementation, commit 4e1a33b1 ("lib: update LZ4 compressor module"), so linux-4.11 and higher would be affected most. However, we probably want to have this backported to all older stable kernels as well, to help with the performance issues. There are two follow-ups that I think we should also work on, but not backport to stable kernels, first to change the asm-generic version of the header to remove the ARM special case, and second to review all other uses of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to see if they might be affected by the same problem on ARM. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
