- 16 May, 2019 40 commits
-
-
Ronnie Sahlberg authored
[ Upstream commit 05fd5c2c ] Commit 088aaf17 introduced a leak where if SMB2_read() returned an error we would return without freeing the request buffer. Cc: Stable <stable@vger.kernel.org> Signed-off-by:
Ronnie Sahlberg <lsahlber@redhat.com> Reviewed-by:
Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com>
-
Damian Kos authored
[ Upstream commit e4056bbb ] This is basically the same fix as in commit fa68d4f8 ("drm/rockchip: fix for mailbox read size") but for cdn_dp_mailbox_validate_receive function. See patchwork.kernel.org/patch/10671981/ for details. Signed-off-by:
Damian Kos <dkos@cadence.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/1542640463-18332-1-git-send-email-dkos@cadence.com Signed-off-by:
-
Florian Westphal authored
[ Upstream commit 0ef235c7 ] ->destroy is only allowed to free data, or do other cleanups that do not have side effects on other state, such as visibility to other netlink requests. Such things need to be done in ->deactivate. As a transaction can fail, we need to make sure we can undo such operations, therefore ->activate() has to be provided too. So print a warning and refuse registration if expr->ops provides only one of the two operations. v2: fix nft_expr_check_ops to not repeat same check twice (Jones Desougi) Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
KT Liao authored
[ Upstream commit 738c06d0 ] There are many Lenovo laptops which need elan_i2c support, this patch adds relevant IDs to the Elan driver so that touchpads are recognized. Signed-off-by:
KT Liao <kt.liao@emc.com.tw> Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Erik Schmauss authored
[ Upstream commit c5781ffb ] ACPICA commit b233720031a480abd438f2e9c643080929d144c3 ASL operation_regions declare a range of addresses that it uses. In a perfect world, the range of addresses should be used exclusively by the AML interpreter. The OS can use this information to decide which drivers to load so that the AML interpreter and device drivers use different regions of memory. During table load, the address information is added to a global address range list. Each node in this list contains an address range as well as a namespace node of the operation_region. This list is deleted at ACPI shutdown. Unfortunately, ASL operation_regions can be declared inside of control methods. Although this is not recommended, modern firmware contains such code. New module level code changes unintentionally removed the functionality of adding and removing nodes to the global address range list. A few months ago, support for adding addresses has been re- implemented. However, the removal of the address range list was missed and resulted in some systems to crash due to the address list containing bogus namespace nodes from operation_regions declared in control methods. In order to fix the crash, this change removes dynamic operation_regions after control method termination. Link: https://github.com/acpica/acpica/commit/b2337200 Link: https://bugzilla.kernel.org/show_bug.cgi?id=202475 Fixes: 4abb951b ("ACPICA: AML interpreter: add region addresses in global list during initialization") Reported-by:
Michael J Gruber <mjg@fedoraproject.org> Signed-off-by:
Erik Schmauss <erik.schmauss@intel.com> Signed-off-by:
Bob Moore <robert.moore@intel.com> Cc: 4.20+ <stable@vger.kernel.org> # 4.20+ Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Matteo Croce authored
[ Upstream commit c22da366 ] Similarly to commit a7603ac1 ("geneve: change NET_UDP_TUNNEL dependency to select"), GTP has a dependency on NET_UDP_TUNNEL which makes impossible to compile it if no other protocol depending on NET_UDP_TUNNEL is selected. Fix this by changing the depends to a select, and drop NET_IP_TUNNEL from the select list, as it already depends on NET_UDP_TUNNEL. Signed-off-by:
Matteo Croce <mcroce@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Cong Wang authored
[ Upstream commit 1db817e7 ] struct tcindex_filter_result contains two parts: struct tcf_exts and struct tcf_result. For the local variable 'cr', its exts part is never used but initialized without being released properly on success path. So just completely remove the exts part to fix this leak. For the local variable 'new_filter_result', it is never properly released if not used by 'r' on success path. Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Max Filippov authored
[ Upstream commit f37598be ] Rename SPI controller node in the XTFPGA DTS to spi@... This fixes the following build warnings: arch/xtensa/boot/dts/kc705_nommu.dtb: Warning (spi_bus_bridge): /soc/spi-master@0d0a0000: node name for SPI buses should be 'spi' arch/xtensa/boot/dts/kc705_nommu.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' arch/xtensa/boot/dts/lx200mx.dtb: Warning (spi_bus_bridge): /soc/spi-master@0d0a0000: node name for SPI buses should be 'spi' arch/xtensa/boot/dts/lx200mx.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' arch/xtensa/boot/dts/kc705.dtb: Warning (spi_bus_bridge): /soc/spi-master@0d0a0000: node name for SPI buses should be 'spi' arch/xtensa/boot/dts/kc705.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' arch/xtensa/boot/dts/ml605.dtb: Warning (spi_bus_bridge): /soc/spi-master@0d0a0000: node name for SPI buses should be 'spi' arch/xtensa/boot/dts/ml605.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' arch/xtensa/boot/dts/lx60.dtb: Warning (spi_bus_bridge): /soc/spi-master@0d0a0000: node name for SPI buses should be 'spi' arch/xtensa/boot/dts/lx60.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
-
Alexey Brodkin authored
[ Upstream commit a66d9724 ] Initially we bumped into problem with 32-bit aligned atomic64_t on ARC, see [1]. And then during quite lengthly discussion Peter Z. mentioned ARCH_KMALLOC_MINALIGN which IMHO makes perfect sense. If allocation is done by plain kmalloc() obtained buffer will be ARCH_KMALLOC_MINALIGN aligned and then why buffer obtained via devm_kmalloc() should have any other alignment? This way we at least get the same behavior for both types of allocation. [1] http://lists.infradead.org/pipermail/linux-snps-arc/2018-July/004009.html [2] http://lists.infradead.org/pipermail/linux-snps-arc/2018-July/004036.html Signed-off-by:
Alexey Brodkin <abrodkin@synopsys.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: David Laight <David.Laight@ACULAB.COM> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Greg KH <greg@kroah.com> Cc: <stable@vger.kernel.org> # 4.8+ Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Nicolas Pitre authored
[ Upstream commit 7e1d2263 ] Every invocation of notify_write() and notify_update() is performed under the console lock, except for one case. Let's fix that. Signed-off-by:
Nicolas Pitre <nico@linaro.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Heinrich Schuchardt authored
[ Upstream commit 132ac39c ] The memory area [0x4000000-0x4200000[ is occupied by the PSCI firmware. Any attempt to access it from Linux leads to an immediate crash. So let's make the same memory reservation as the vendor kernel. [gregory: added as comment that this region matches the mainline U-boot] Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by:
Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by:
-
Adit Ranadive authored
[ Upstream commit 6325e01b ] Since the IB_WR_REG_MR opcode value changed, let's set the PVRDMA device opcodes explicitly. Reported-by:
Ruishuang Wang <ruishuangw@vmware.com> Fixes: 9a59739b ("IB/rxe: Revise the ib_wr_opcode enum") Cc: stable@vger.kernel.org Reviewed-by:
Bryan Tan <bryantan@vmware.com> Reviewed-by:
Vishnu Dasa <vdasa@vmware.com> Signed-off-by:
Adit Ranadive <aditr@vmware.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Enric Balletbo i Serra authored
[ Upstream commit 4eda776c ] 'encoder' is dereferenced before it is null sanity checked, hence we potentially have a null pointer dereference bug. Instead, initialise drm_drv from encoder->dev->dev_private after we are sure 'encoder' is not null. Fixes: 5182c1a5 ("drm/rockchip: add an common abstracted PSR driver") Cc: stable@vger.kernel.org Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
-
Jerome Brunet authored
[ Upstream commit 9aec3037 ] When probing, if we fail to get the pwm due to probe deferal, we shouldn't print an error message. Just be silent in this case. Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by:
-
Nicholas Piggin authored
[ Upstream commit f2910f0e ] GCC 4.6 is the minimum supported now. Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Reviewed-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Marc Zyngier authored
[ Upstream commit c987876a ] Contrary to the non-VHE version of the TLB invalidation helpers, the VHE code has interrupts enabled, meaning that we can take an interrupt in the middle of such a sequence, and start running something else with HCR_EL2.TGE cleared. That's really not a good idea. Take the heavy-handed option and disable interrupts in __tlb_switch_to_guest_vhe, restoring them in __tlb_switch_to_host_vhe. The latter also gain an ISB in order to make sure that TGE really has taken effect. Cc: stable@vger.kernel.org Acked-by:
Christoffer Dall <christoffer.dall@arm.com> Reviewed-by:
James Morse <james.morse@arm.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Martin Schwidefsky authored
[ Upstream commit 1071fc57 ] Add three architecture overrideable functions to test if the p4d, pud, or pmd layer of a page table is folded or not. Acked-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Alistair Strachan authored
[ Upstream commit cd01544a ] Commit 379d98dd ("x86: vdso: Use $LD instead of $CC to link") accidentally broke unwinding from userspace, because ld would strip the .eh_frame sections when linking. Originally, the compiler would implicitly add --eh-frame-hdr when invoking the linker, but when this Makefile was converted from invoking ld via the compiler, to invoking it directly (like vmlinux does), the flag was missed. (The EH_FRAME section is important for the VDSO shared libraries, but not for vmlinux.) Fix the problem by explicitly specifying --eh-frame-hdr, which restores parity with the old method. See relevant bug reports for additional info: https://bugzilla.kernel.org/show_bug.cgi?id=201741 https://bugzilla.redhat.com/show_bug.cgi?id=1659295 Fixes: 379d98dd ("x86: vdso: Use $LD instead of $CC to link") Reported-by:
Florian Weimer <fweimer@redhat.com> Reported-by:
Carlos O'Donell <carlos@redhat.com> Reported-by:
"H. J. Lu" <hjl.tools@gmail.com> Signed-off-by:
Alistair Strachan <astrachan@google.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Tested-by:
Laura Abbott <labbott@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Carlos O'Donell <carlos@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Joel Fernandes <joel@joelfernandes.org> Cc: kernel-team@android.com Cc: Laura Abbott <labbott@redhat.com> Cc: stable <stable@vger.kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: X86 ML <x86@kernel.org> Link: https://lkml.kernel.org/r/20181214223637.35954-1-astrachan@google.com Signed-off-by:
-
Omar Sandoval authored
[ Upstream commit d6fd0ae2 ] There's a race between close_ctree() and cleaner_kthread(). close_ctree() sets btrfs_fs_closing(), and the cleaner stops when it sees it set, but this is racy; the cleaner might have already checked the bit and could be cleaning stuff. In particular, if it deletes unused block groups, it will create delayed iputs for the free space cache inodes. As of "btrfs: don't run delayed_iputs in commit", we're no longer running delayed iputs after a commit. Therefore, if the cleaner creates more delayed iputs after delayed iputs are run in btrfs_commit_super(), we will leak inodes on unmount and get a busy inode crash from the VFS. Fix it by parking the cleaner before we actually close anything. Then, any remaining delayed iputs will always be handled in btrfs_commit_super(). This also ensures that the commit in close_ctree() is really the last commit, so we can get rid of the commit in cleaner_kthread(). The fstest/generic/475 followed by 476 can trigger a crash that manifests as a slab corruption caused by accessing the freed kthread structure by a wake up function. Sample trace: [ 5657.077612] BUG: unable to handle kernel NULL pointer dereference at 00000000000000cc [ 5657.079432] PGD 1c57a067 P4D 1c57a067 PUD da10067 PMD 0 [ 5657.080661] Oops: 0000 [#1] PREEMPT SMP [ 5657.081592] CPU: 1 PID: 5157 Comm: fsstress Tainted: G W 4.19.0-rc8-default+ #323 [ 5657.083703] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626cc-prebuilt.qemu-project.org 04/01/2014 [ 5657.086577] RIP: 0010:shrink_page_list+0x2f9/0xe90 [ 5657.091937] RSP: 0018:ffffb5c745c8f728 EFLAGS: 00010287 [ 5657.092953] RAX: 0000000000000074 RBX: ffffb5c745c8f830 RCX: 0000000000000000 [ 5657.094590] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff9a8747fdf3d0 [ 5657.095987] RBP: ffffb5c745c8f9e0 R08: 0000000000000000 R09: 0000000000000000 [ 5657.097159] R10: ffff9a8747fdf5e8 R11: 0000000000000000 R12: ffffb5c745c8f788 [ 5657.098513] R13: ffff9a877f6ff2c0 R14: ffff9a877f6ff2c8 R15: dead000000000200 [ 5657.099689] FS: 00007f948d853b80(0000) GS:ffff9a877d600000(0000) knlGS:0000000000000000 [ 5657.101032] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5657.101953] CR2: 00000000000000cc CR3: 00000000684bd000 CR4: 00000000000006e0 [ 5657.103159] Call Trace: [ 5657.103776] shrink_inactive_list+0x194/0x410 [ 5657.104671] shrink_node_memcg.constprop.84+0x39a/0x6a0 [ 5657.105750] shrink_node+0x62/0x1c0 [ 5657.106529] try_to_free_pages+0x1a4/0x500 [ 5657.107408] __alloc_pages_slowpath+0x2c9/0xb20 [ 5657.108418] __alloc_pages_nodemask+0x268/0x2b0 [ 5657.109348] kmalloc_large_node+0x37/0x90 [ 5657.110205] __kmalloc_node+0x236/0x310 [ 5657.111014] kvmalloc_node+0x3e/0x70 Fixes: 30928e9b ("btrfs: don't run delayed_iputs in commit") Signed-off-by:
Omar Sandoval <osandov@fb.com> Reviewed-by:
David Sterba <dsterba@suse.com> [ add trace ] Signed-off-by:
-
Thierry Reding authored
[ Upstream commit 5f2b8b62 ] Setting up and tearing down debugfs is current unbalanced, as seen by this error during resume from suspend: [ 752.134067] dwc-eth-dwmac 2490000.ethernet eth0: ERROR failed to create debugfs directory [ 752.134347] dwc-eth-dwmac 2490000.ethernet eth0: stmmac_hw_setup: failed debugFS registration The imbalance happens because the driver creates the debugfs hierarchy when the device is opened and tears it down when the device is closed. There's little gain in that, and it could be argued that it is even surprising because it's not usually done for other devices. Fix the imbalance by moving the debugfs creation and teardown to the driver's ->probe() and ->remove() implementations instead. Note that the ring descriptors cannot be read while the interface is down, so make sure to return an empty file when the descriptors_status debugfs file is read. Signed-off-by:
Thierry Reding <treding@nvidia.com> Acked-by:
Jose Abreu <joabreu@synopsys.com> Signed-off-by:
-
Lubomir Rintel authored
[ Upstream commit 33f49571 ] WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n] Selected by [y]: - FB_OLPC_DCON [=y] && STAGING [=y] && X86 [=y] && OLPC [=y] && FB [=y] && I2C [=y] && (GPIO_CS5535 [=n] || GPIO_CS5535 [=n]=n) Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 0eeec014 ] I ran into a new warning on randconfig kernels: drivers/scsi/raid_class.c: In function 'raid_match': drivers/scsi/raid_class.c:64:24: error: unused variable 'i' [-Werror=unused-variable] This looks like a very old problem that for some reason was very hard to run into, but it is very easy to fix, by replacing the incorrect #ifdef with a simpler IS_ENABLED() check. Fixes: fac829fd ("[SCSI] raid_attrs: fix dependency problems") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Chris Wilson authored
[ Upstream commit 86c1c87d ] According to intel_read_wm_latency() it is perfectly legal for one WM and all subsequent levels to be 0 (and the deeper powersaving states disabled), so don't shout *ERROR*, over and over again. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180726161527.10516-1-chris@chris-wilson.co.uk Signed-off-by:
-
Steven Rostedt (VMware) authored
[ Upstream commit 5cf99a0f ] The tracefs file set_graph_function is used to only function graph functions that are listed in that file (or all functions if the file is empty). The way this is implemented is that the function graph tracer looks at every function, and if the current depth is zero and the function matches something in the file then it will trace that function. When other functions are called, the depth will be greater than zero (because the original function will be at depth zero), and all functions will be traced where the depth is greater than zero. The issue is that when a function is first entered, and the handler that checks this logic is called, the depth is set to zero. If an interrupt comes in and a function in the interrupt handler is traced, its depth will be greater than zero and it will automatically be traced, even if the original function was not. But because the logic only looks at depth it may trace interrupts when it should not be. The recent design change of the function graph tracer to fix other bugs caused the depth to be zero while the function graph callback handler is being called for a longer time, widening the race of this happening. This bug was actually there for a longer time, but because the race window was so small it seldom happened. The Fixes tag below is for the commit that widen the race window, because that commit belongs to a series that will also help fix the original bug. Cc: stable@kernel.org Fixes: 39eb456d ("function_graph: Use new curr_ret_depth to manage depth instead of curr_ret_stack") Reported-by:
Joe Lawrence <joe.lawrence@redhat.com> Tested-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Paolo Abeni authored
[ Upstream commit 605108ac ] Eric noted that with UDP GRO and NAPI timeout, we could keep a single UDP packet inside the GRO hash forever, if the related NAPI instance calls napi_gro_complete() at an higher frequency than the NAPI timeout. Willem noted that even TCP packets could be trapped there, till the next retransmission. This patch tries to address the issue, flushing the old packets - those with a NAPI_GRO_CB age before the current jiffy - before scheduling the NAPI timeout. The rationale is that such a timeout should be well below a jiffy and we are not flushing packets eligible for sane GRO. v1 -> v2: - clarified the commit message and comment RFC -> v1: - added 'Fixes tags', cleaned-up the wording. Reported-by:
Eric Dumazet <eric.dumazet@gmail.com> Fixes: 3b47d303 ("net: gro: add a per device gro flush timer") Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Acked-by:
Willem de Bruijn <willemb@google.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Hugues Fruchet authored
[ Upstream commit a8f438c6 ] When switching from auto to manual mode, V4L2 core is calling g_volatile_ctrl() in manual mode in order to get the manual initial value. Remove the manual mode check/return to not break this behaviour. Signed-off-by:
Hugues Fruchet <hugues.fruchet@st.com> Tested-by:
Jacopo Mondi <jacopo@jmondi.org> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Hugues Fruchet authored
[ Upstream commit c2c3f42d ] ov5640_set_mode_exposure_calc() is checking binning value but binning value read is buggy, fix this. Rename ov5640_binning_on() to ov5640_get_binning() as per other similar functions. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Ville Syrjälä authored
[ Upstream commit 03981c6e ] I have a Thinkpad X220 Tablet in my hands that is losing vblank interrupts whenever LP3 watermarks are used. If I nudge the latency value written to the WM3 register just by one in either direction the problem disappears. That to me suggests that the punit will not enter the corrsponding powersave mode (MPLL shutdown IIRC) unless the latency value in the register matches exactly what we read from SSKPD. Ie. it's not really a latency value but rather just a cookie by which the punit can identify the desired power saving state. On HSW/BDW this was changed such that we actually just write the WM level number into those bits, which makes much more sense given the observed behaviour. We could try to handle this by disallowing LP3 watermarks only when vblank interrupts are enabled but we'd first have to prove that only vblank interrupts are affected, which seems unlikely. Also we can't grab the wm mutex from the vblank enable/disable hooks because those are called with various spinlocks held. Thus we'd have to redesigne the watermark locking. So to play it safe and keep the code simple we simply disable LP3 watermarks on all SNB machines. To do that we simply zero out the latency values for watermark level 3, and we adjust the watermark computation to check for that. The behaviour now matches that of the g4x/vlv/skl wm code in the presence of a zeroed latency value. v2: s/USHRT_MAX/U32_MAX/ for consistency with the types (Chris) Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181114173440.6730-1-ville.syrjala@linux.intel.com Signed-off-by:
-
Miklos Szeredi authored
[ Upstream commit 2d84a2d1 ] In current fuse_drop_waiting() implementation it's possible that fuse_wait_aborted() will not be woken up in the unlikely case that fuse_abort_conn() + fuse_wait_aborted() runs in between checking fc->connected and calling atomic_dec(&fc->num_waiting). Do the atomic_dec_and_test() unconditionally, which also provides the necessary barrier against reordering with the fc->connected check. The explicit smp_mb() in fuse_wait_aborted() is not actually needed, since the spin_unlock() in fuse_abort_conn() provides the necessary RELEASE barrier after resetting fc->connected. However, this is not a performance sensitive path, and adding the explicit barrier makes it easier to document. Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Fixes: b8f95e5d ("fuse: umount should wait for all requests") Cc: <stable@vger.kernel.org> #v4.19 Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit ab83203e ] When there is no EDID the CEC adapter should be unconfigured as well. So call cec_phys_addr_invalidate() when this happens. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Cc: <stable@vger.kernel.org> # for v4.18 and up Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit e7da8992 ] When there is no EDID the CEC adapter should be unconfigured as well. So call cec_phys_addr_invalidate() when this happens. Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit e81bff39 ] The cec_phys_addr_validate() function will be moved to V4L2, so use a simplified variant of that function in cec-api.c. cec now no longer calls cec_phys_addr_validate() and it can be safely moved to V4L2. Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit b915bf57 ] This function is needed by both V4L2 and CEC, so move this to cec.h as a static inline since there are no obvious shared modules between the two subsystems. This patch, together with the following ones, fixes a dependency bug: if CEC_CORE is disabled, then building adv7604 (and other HDMI receivers) will fail because an essential function is now stubbed out. Signed-off-by:
-
Punit Agrawal authored
[ Upstream commit fd2ef358 ] PageTransCompoundMap() returns true for hugetlbfs and THP hugepages. This behaviour incorrectly leads to stage 2 faults for unsupported hugepage sizes (e.g., 64K hugepage with 4K pages) to be treated as THP faults. Tighten the check to filter out hugetlbfs pages. This also leads to consistently mapping all unsupported hugepage sizes as PTE level entries at stage 2. Signed-off-by:
Punit Agrawal <punit.agrawal@arm.com> Reviewed-by:
Suzuki Poulose <suzuki.poulose@arm.com> Cc: Christoffer Dall <christoffer.dall@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: stable@vger.kernel.org # v4.13+ Signed-off-by:
-
Goldwyn Rodrigues authored
[ Upstream commit a408e4a8 ] Open a new file instance as opposed to changing file->f_mode when the file is not readable. This is done to accomodate overlayfs stacked file operations change. The real struct file is hidden behind the overlays struct file. So, any file->f_mode manipulations are not reflected on the real struct file. Open the file again in read mode if original file cannot be read, read and calculate the hash. Signed-off-by:
Goldwyn Rodrigues <rgoldwyn@suse.com> Cc: stable@vger.kernel.org (linux-4.19) Signed-off-by:
Mimi Zohar <zohar@linux.ibm.com> Signed-off-by:
-
Jason Gunthorpe authored
[ Upstream commit 9a59739b ] This enum has become part of the uABI, as both RXE and the ib_uverbs_post_send() command expect userspace to supply values from this enum. So it should be properly placed in include/uapi/rdma. In userspace this enum is called 'enum ibv_wr_opcode' as part of libibverbs.h. That enum defines different values for IB_WR_LOCAL_INV, IB_WR_SEND_WITH_INV, and IB_WR_LSO. These were introduced (incorrectly, it turns out) into libiberbs in 2015. The kernel has changed its mind on the numbering for several of the IB_WC values over the years, but has remained stable on IB_WR_LOCAL_INV and below. Based on this we can conclude that there is no real user space user of the values beyond IB_WR_ATOMIC_FETCH_AND_ADD, as they have never worked via rdma-core. This is confirmed by inspection, only rxe uses the kernel enum and implements the latter operations. rxe has clearly never worked with these attributes from userspace. Other drivers that support these opcodes implement the functionality without calling out to the kernel. To make IB_WR_SEND_WITH_INV and related work for RXE in userspace we choose to renumber the IB_WR enum in the kernel to match the uABI that userspace has bee using since before Soft RoCE was merged. This is an overall simpler configuration for the whole software stack, and obviously can't break anything existing. Reported-by:
Seth Howell <seth.howell@intel.com> Tested-by:
-
Erik Schmauss authored
[ Upstream commit 4abb951b ] The table load process omitted adding the operation region address range to the global list. This omission is problematic because the OS queries the global list to check for address range conflicts before deciding which drivers to load. This commit may result in warning messages that look like the following: [ 7.871761] ACPI Warning: system_IO range 0x00000428-0x0000042F conflicts with op_region 0x00000400-0x0000047F (\PMIO) (20180531/utaddress-213) [ 7.871769] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver However, these messages do not signify regressions. It is a result of properly adding address ranges within the global address list. Link: https://bugzilla.kernel.org/show_bug.cgi?id=200011 Tested-by:
Jean-Marc Lenoir <archlinux@jihemel.com> Signed-off-by:
-
Tang Junhui authored
[ Upstream commit 2e17a262 ] When bcache device is clean, dirty keys may still exist after journal replay, so we need to count these dirty keys even device in clean status, otherwise after writeback, the amount of dirty data would be incorrect. Signed-off-by:
Tang Junhui <tang.junhui.linux@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Coly Li <colyli@suse.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Huacai Chen authored
[ Upstream commit c61c7def ] Commit ea7e0480 ("MIPS: VDSO: Always map near top of user memory") set VDSO_RANDOMIZE_SIZE to 256MB for 64bit kernel. But take a look at arch/mips/mm/mmap.c we can see that MIN_GAP is 128MB, which means the mmap_base may be at (user_address_top - 128MB). This make the stack be surrounded by mmaped areas, then stack expanding fails and causes a segmentation fault. Therefore, VDSO_RANDOMIZE_SIZE should be less than MIN_GAP and this patch reduce it to 64MB. Signed-off-by:
Huacai Chen <chenhc@lemote.com> Signed-off-by:
Paul Burton <paul.burton@mips.com> Fixes: ea7e0480 ("MIPS: VDSO: Always map near top of user memory") Patchwork: https://patchwork.linux-mips.org/patch/20910/ Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Cc: Huacai Chen <chenhuacai@gmail.com> Signed-off-by:
-
David Miller authored
[ Upstream commit 5b4fc388 ] Right now if we get a corrupted user stack frame we do a do_exit(SIGILL) which is not helpful. If under a debugger, this behavior causes the inferior process to exit. So the register and other state cannot be examined at the time of the event. Instead, conditionally log a rate limited kernel log message and then force a SIGSEGV. With bits and ideas borrowed (as usual) from powerpc. Signed-off-by:
-
