- 06 Jun, 2018 26 commits
-
-
Maciej W. Rozycki authored
commit c7e81462 upstream. Use 64-bit accesses for 64-bit floating-point general registers with PTRACE_PEEKUSR, removing the truncation of their upper halves in the FR=1 mode, caused by commit bbd426f5 ("MIPS: Simplify FP context access"), which inadvertently switched them to using 32-bit accesses. The PTRACE_POKEUSR side is fine as it's never been broken and continues using 64-bit accesses. Fixes: bbd426f5 ("MIPS: Simplify FP context access") Signed-off-by:
Maciej W. Rozycki <macro@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 3.15+ Patchwork: https://patchwork.linux-mips.org/patch/19334/Signed-off-by:
James Hogan <jhogan@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Martin Kelly authored
commit 3d13de4b upstream. Currently, the following causes a kernel OOPS in memcpy: echo 1073741825 > buffer/length echo 1 > buffer/enable Note that using 1073741824 instead of 1073741825 causes "write error: Cannot allocate memory" but no OOPS. This is because 1073741824 == 2^30 and 1073741825 == 2^30+1. Since kfifo rounds up to the nearest power of 2, it will actually call kmalloc with roundup_pow_of_two(length) * bytes_per_datum. Using length == 1073741825 and bytes_per_datum == 2, we get: kmalloc(roundup_pow_of_two(1073741825) * 2 or kmalloc(2147483648 * 2) or kmalloc(4294967296) or kmalloc(UINT_MAX + 1) so this overflows to 0, causing kmalloc to return ZERO_SIZE_PTR and subsequent memcpy to fail once the device is enabled. Fix this by checking for overflow prior to allocating a kfifo. With this check added, the above code returns -EINVAL when enabling the buffer, rather than causing an OOPS. Signed-off-by:
Martin Kelly <mkelly@xevo.com> cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Yoshihiro Shimoda authored
commit d9f5efad upstream. This patch fixes an issue that list_for_each_entry() in usb_dmac_chan_terminate_all() is possible to cause endless loop because this will move own desc to the desc_freed. So, this driver should use list_for_each_entry_safe() instead of list_for_each_entry(). Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
Biju Das <biju.das@bp.renesas.com> Signed-off-by:
-
Wolfram Sang authored
commit 52df445f upstream. If we don't clear START generation as soon as possible, it may cause another message to be generated, e.g. when receiving NACK in address phase. To keep the race window as small as possible, we clear it right at the beginning of the interrupt. We don't need any checks since we always want to stop START and STOP generation on the next occasion after we started it. This patch improves the situation but sadly does not completely fix it. It is still to be researched if we can do better given this HW design. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by:
-
Wolfram Sang authored
commit c3be0af1 upstream. Due to the HW design, master IRQs are timing critical, so give them precedence over slave IRQ. Signed-off-by:
-
Wolfram Sang authored
commit d89667b1 upstream. The manual says (55.4.8.6) that HW does automatically send STOP after NACK was received. My measuerments confirm that. Signed-off-by:
-
Wolfram Sang authored
commit cc21d0b4 upstream. Setting up new messages was done in process context while handling a message was in interrupt context. Because of the HW design, this IP core is sensitive to timing, so the context switches were too expensive. Move this setup to interrupt context as well. In my test setup, this fixed the occasional 'data byte sent twice' issue which a number of people have seen. It also fixes to send REP_START after a read message which was wrongly send as a STOP + START sequence before. Signed-off-by:
Chris Paterson <Chris.Paterson2@renesas.com> Signed-off-by:
-
Wolfram Sang authored
commit b9d0684c upstream. We want to reuse this function later. Signed-off-by:
-
Wolfram Sang authored
commit ff2316b8 upstream. After making sure to reinit the HW and clear interrupts in the timeout case, we know that interrupts are always disabled in the sections protected by the spinlock. Thus, we can simply remove it which is a preparation for further refactoring. While here, rename the timeout variable to time_left which is way more readable. Signed-off-by:
-
Wolfram Sang authored
commit 90f779e5 upstream. Signed-off-by:
-
Wolfram Sang authored
commit 2c78cdc1 upstream. We don't need to init HW before every transfer since we know the HW state then. HW init at probe time is enough. While here, add setting the clock register which belongs to init HW. Also, set MDBS bit since not setting it is prohibited according to the manual. Signed-off-by:
-
Wolfram Sang authored
commit e43e0df1 upstream. When calculating the bus speed, the clock should be on, of course. Most bootloaders left them on, so this went unnoticed so far. Move the ioremapping out of this clock-enabled-block and prepare for adding hw initialization there, too. Reported-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
-
Eric Dumazet authored
commit 607065ba upstream. When using large tcp_rmem[2] values (I did tests with 500 MB), I noticed overflows while computing rcvwin. Lets fix this before the following patch. Signed-off-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Soheil Hassas Yeganeh <soheil@google.com> Acked-by:
Wei Wang <weiwan@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> [Backport: sysctl_tcp_rmem is not Namespace-ify'd in older kernels] Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Arnd Bergmann authored
commit c9bd2823 upstream. irda_get_mtt() returns a hardcoded '10000' in some cases, and with gcc-7, we get a build error because this triggers a compile-time check in udelay(): drivers/net/irda/w83977af_ir.o: In function `w83977af_hard_xmit': w83977af_ir.c:(.text.w83977af_hard_xmit+0x14c): undefined reference to `__bad_udelay' Older compilers did not run into this because they either did not completely inline the irda_get_mtt() or did not consider the 10000 value a constant expression. The code has been wrong since the start of git history. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Colin Ian King authored
commit 271ef65b upstream. The pointer dma_dev_name is assigned but never read, it is redundant and can therefore be removed. Cleans up clang warning: sound/soc/intel/common/sst-firmware.c:288:3: warning: Value stored to 'dma_dev_name' is never read Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Matthias Kaehlcke authored
commit fb239c12 upstream. In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal is assigned to itself in an if ... else statement, apparently only to document that the branch condition is handled and that a previously read value should be returned unmodified. The self-assignment causes clang to raise the following warning: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:304:13: error: explicitly assigning value of variable of type 'u32' (aka 'unsigned int') to itself [-Werror,-Wself-assign] writeVal = writeVal; Delete the branch with the self-assignment. Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Reviewed-by:
Guenter Roeck <groeck@chromium.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Eric Biggers authored
commit 81459649 upstream. wiphy names were recently limited to 128 bytes by commit a7cfebcb ("cfg80211: limit wiphy names to 128 bytes"). As it turns out though, this isn't sufficient because dev_vprintk_emit() needs the syslog header string "SUBSYSTEM=ieee80211\0DEVICE=+ieee80211:$devname" to fit into 128 bytes. This triggered the "device/subsystem name too long" WARN when the device name was >= 90 bytes. As before, this was reproduced by syzbot by sending an HWSIM_CMD_NEW_RADIO command to the MAC80211_HWSIM generic netlink family. Fix it by further limiting wiphy names to 64 bytes. Reported-by: syzbot+e64565577af34b3768dc@syzkaller.appspotmail.com Fixes: a7cfebcb ("cfg80211: limit wiphy names to 128 bytes") Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Sachin Grover authored
commit efe3de79 upstream. Call trace: [<ffffff9203a8d7a8>] dump_backtrace+0x0/0x428 [<ffffff9203a8dbf8>] show_stack+0x28/0x38 [<ffffff920409bfb8>] dump_stack+0xd4/0x124 [<ffffff9203d187e8>] print_address_description+0x68/0x258 [<ffffff9203d18c00>] kasan_report.part.2+0x228/0x2f0 [<ffffff9203d1927c>] kasan_report+0x5c/0x70 [<ffffff9203d1776c>] check_memory_region+0x12c/0x1c0 [<ffffff9203d17cdc>] memcpy+0x34/0x68 [<ffffff9203d75348>] xattr_getsecurity+0xe0/0x160 [<ffffff9203d75490>] vfs_getxattr+0xc8/0x120 [<ffffff9203d75d68>] getxattr+0x100/0x2c8 [<ffffff9203d76fb4>] SyS_fgetxattr+0x64/0xa0 [<ffffff9203a83f70>] el0_svc_naked+0x24/0x28 If user get root access and calls security.selinux setxattr() with an embedded NUL on a file and then if some process performs a getxattr() on that file with a length greater than the actual length of the string, it would result in a panic. To fix this, add the actual length of the string to the security context instead of the length passed by the userspace process. Signed-off-by:
Sachin Grover <sgrover@codeaurora.org> Cc: stable@vger.kernel.org Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Steven Rostedt (VMware) authored
commit 86b389ff upstream. If a instance has an event trigger enabled when it is freed, it could cause an access of free memory. Here's the case that crashes: # cd /sys/kernel/tracing # mkdir instances/foo # echo snapshot > instances/foo/events/initcall/initcall_start/trigger # rmdir instances/foo Would produce: general protection fault: 0000 [#1] PREEMPT SMP PTI Modules linked in: tun bridge ... CPU: 5 PID: 6203 Comm: rmdir Tainted: G W 4.17.0-rc4-test+ #933 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:clear_event_triggers+0x3b/0x70 RSP: 0018:ffffc90003783de0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 6b6b6b6b6b6b6b2b RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800c7130ba0 RBP: ffffc90003783e00 R08: ffff8801131993f8 R09: 0000000100230016 R10: ffffc90003783d80 R11: 0000000000000000 R12: ffff8800c7130ba0 R13: ffff8800c7130bd8 R14: ffff8800cc093768 R15: 00000000ffffff9c FS: 00007f6f4aa86700(0000) GS:ffff88011eb40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6f4a5aed60 CR3: 00000000cd552001 CR4: 00000000001606e0 Call Trace: event_trace_del_tracer+0x2a/0xc5 instance_rmdir+0x15c/0x200 tracefs_syscall_rmdir+0x52/0x90 vfs_rmdir+0xdb/0x160 do_rmdir+0x16d/0x1c0 __x64_sys_rmdir+0x17/0x20 do_syscall_64+0x55/0x1a0 entry_SYSCALL_64_after_hwframe+0x49/0xbe This was due to the call the clears out the triggers when an instance is being deleted not removing the trigger from the link list. Cc: stable@vger.kernel.org Fixes: 85f2b082 ("tracing: Add basic event trigger framework") Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Benjamin Tissoires authored
commit 40f7090b upstream. New ICs (like the one on the Lenovo T480s) answer to ETP_SMBUS_IAP_VERSION_CMD 4 bytes instead of 3. This corrupts the stack as i2c_smbus_read_block_data() uses the values returned by the i2c device to know how many data it need to return. i2c_smbus_read_block_data() can read up to 32 bytes (I2C_SMBUS_BLOCK_MAX) and there is no safeguard on how many bytes are provided in the return value. Ensure we always have enough space for any future firmware. Also 0-initialize the values to prevent any access to uninitialized memory. Cc: <stable@vger.kernel.org> # v4.4.x, v4.9.x, v4.14.x, v4.15.x, v4.16.x Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by:
KT Liao <kt.liao@emc.com.tw> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Mimi Zohar authored
commit f5acb3dc upstream. Userspace applications have been modified to write security xattrs, but they are not context aware. In the case of security.ima, the security xattr can be either a file hash or a file signature. Permitting writing one, but not the other requires the application to be context aware. In addition, userspace applications might write files to a staging area, which might not be in policy, and then change some file metadata (eg. owner) making it in policy. As a result, these files are not labeled properly. This reverts commit c68ed80c, which prevents writing file hashes as security.ima xattrs. Requested-by:
Patrick Ohly <patrick.ohly@intel.com> Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com> Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> Signed-off-by:
-
Brian Foster authored
commit a27ba260 upstream. The struct xfs_agfl v5 header was originally introduced with unexpected padding that caused the AGFL to operate with one less slot than intended. The header has since been packed, but the fix left an incompatibility for users who upgrade from an old kernel with the unpacked header to a newer kernel with the packed header while the AGFL happens to wrap around the end. The newer kernel recognizes one extra slot at the physical end of the AGFL that the previous kernel did not. The new kernel will eventually attempt to allocate a block from that slot, which contains invalid data, and cause a crash. This condition can be detected by comparing the active range of the AGFL to the count. While this detects a padding mismatch, it can also trigger false positives for unrelated flcount corruption. Since we cannot distinguish a size mismatch due to padding from unrelated corruption, we can't trust the AGFL enough to simply repopulate the empty slot. Instead, avoid unnecessarily complex detection logic and and use a solution that can handle any form of flcount corruption that slips through read verifiers: distrust the entire AGFL and reset it to an empty state. Any valid blocks within the AGFL are intentionally leaked. This requires xfs_repair to rectify (which was already necessary based on the state the AGFL was found in). The reset mitigates the side effect of the padding mismatch problem from a filesystem crash to a free space accounting inconsistency. The generic approach also means that this patch can be safely backported to kernels with or without a packed struct xfs_agfl. Check the AGF for an invalid freelist count on initial read from disk. If detected, set a flag on the xfs_perag to indicate that a reset is required before the AGFL can be used. In the first transaction that attempts to use a flagged AGFL, reset it to empty, warn the user about the inconsistency and allow the freelist fixup code to repopulate the AGFL with new blocks. The xfs_perag flag is cleared to eliminate the need for repeated checks on each block allocation operation. This allows kernels that include the packing fix commit 96f859d5 ("libxfs: pack the agfl header structure so XFS_AGFL_SIZE is correct") to handle older unpacked AGFL formats without a filesystem crash. Suggested-by:
Dave Chinner <david@fromorbit.com> Signed-off-by:
Brian Foster <bfoster@redhat.com> Reviewed-by:
Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by Dave Chiluk <chiluk+linuxxfs@indeed.com> Signed-off-by:
Dave Chiluk <chiluk+linuxxfs@indeed.com> Signed-off-by:
-
Yoshinori Sato authored
commit 940d4113 upstream. New gcc (4.8 or later) used new shift helper functions. So we need added new helper to private libgcc. Signed-off-by:
Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by:
Rich Felker <dalias@libc.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Geert Uytterhoeven authored
commit 009615ab upstream. On sparc32, tcflag_t is unsigned long, unlike all other architectures: drivers/usb/serial/cp210x.c: In function 'cp210x_get_termios': drivers/usb/serial/cp210x.c:717:3: warning: passing argument 2 of 'cp210x_get_termios_port' from incompatible pointer type cp210x_get_termios_port(tty->driver_data, ^ drivers/usb/serial/cp210x.c:35:13: note: expected 'unsigned int *' but argument is of type 'tcflag_t *' static void cp210x_get_termios_port(struct usb_serial_port *port, ^ Consistently use tcflag_t to fix this. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Johan Hovold <johan@kernel.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Michael Neuling authored
commit faf37c44 upstream. Clear the PCR (Processor Compatibility Register) on boot to ensure we are not running in a compatibility mode. We've seen this cause problems when a crash (and kdump) occurs while running compat mode guests. The kdump kernel then runs with the PCR set and causes problems. The symptom in the kdump kernel (also seen in petitboot after fast-reboot) is early userspace programs taking sigills on newer instructions (seen in libc). Signed-off-by:
Michael Neuling <mikey@neuling.org> Cc: stable@vger.kernel.org Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Will Deacon authored
commit 32c3fa7c upstream. For LSE atomics that read and write a register operand, we need to ensure that these operands are annotated as "early clobber" if the register is written before all of the input operands have been consumed. Failure to do so can result in the compiler allocating the same register to both operands, leading to splats such as: Unable to handle kernel paging request at virtual address 11111122222221 [...] x1 : 1111111122222222 x0 : 1111111122222221 Process swapper/0 (pid: 1, stack limit = 0x000000008209f908) Call trace: test_atomic64+0x1360/0x155c where x0 has been allocated as both the value to be stored and also the atomic_t pointer. This patch adds the missing clobbers. Cc: <stable@vger.kernel.org> Cc: Dave Martin <dave.martin@arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Reported-by:
Mark Salter <msalter@redhat.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
- 30 May, 2018 14 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
This reverts commit 33cebc97 which is 03080e5e ("vti4: Don't override MTU passed on link creation via IFLA_MTU") upstream as it causes test failures. This commit should not have been backported to anything older than 4.16, despite what the changelog said as the mtu must be set in older kernels, unlike is needed in 4.16 and newer. Thanks to Alistair Strachan for the debugging help figuring this out, and for 'git bisect' for making my life a whole lot easier. Cc: Alistair Strachan <astrachan@google.com> Cc: Stefano Brivio <sbrivio@redhat.com> Cc: Sabrina Dubroca <sd@queasysnail.net> Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
-
Greg Kroah-Hartman authored
-
Martin Schwidefsky authored
commit 23a4d7fd upstream. The return from the ftrace_stub, _mcount, ftrace_caller and return_to_handler functions is done with "br %r14" and "br %r1". These are indirect branches as well and need to use execute trampolines for CONFIG_EXPOLINE=y. The ftrace_caller function is a special case as it returns to the start of a function and may only use %r0 and %r1. For a pre z10 machine the standard execute trampoline uses a LARL + EX to do this, but this requires *two* registers in the range %r1..%r15. To get around this the 'br %r1' located in the lowcore is used, then the EX instruction does not need an address register. But the lowcore trick may only be used for pre z14 machines, with noexec=on the mapping for the first page may not contain instructions. The solution for that is an ALTERNATIVE in the expoline THUNK generated by 'GEN_BR_THUNK %r1' to switch to EXRL, this relies on the fact that a machine that supports noexec=on has EXRL as well. Cc: stable@vger.kernel.org # 4.16 Fixes: f19fbd5e ("s390: introduce execute-trampolines for branches") Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Randy Dunlap authored
[ Upstream commit 1e0ce03b ] The "mdr" command should repeat (continue) when only Enter/Return is pressed, so make it do so. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: kgdb-bugreport@lists.sourceforge.net Signed-off-by:
Jason Wessel <jason.wessel@windriver.com> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
-
Larry Finger authored
[ Upstream commit fed03fe7 ] The Asus Z370-I contains a Realtek RTL8822BE device with an associated BT chip using a USB ID of 0b05:185c. This device is added to the driver. Signed-off-by:
Hon Weng Chong <honwchong@gmail.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Sylwester Nawrocki authored
[ Upstream commit 647d04f8 ] If the RCLK mux clock configuration is specified in DT and no set_sysclk() callback is used in the sound card driver the sclk_srcrate field will remain set to 0, leading to an incorrect PSR divider setting. To fix this the frequency value is retrieved from the CLK_I2S_RCLK_SRC clock, so the actual RCLK mux selection is taken into account. Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Acked-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 30966861 ] If an unlikely failure in 'of_get_regulator_init_data()' occurs, we must release the reference on the current 'child' node before returning. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
James Smart authored
[ Upstream commit 04673e38 ] The driver controls when the hardware sends completions that communicate consumption of elements from the WQ. This is done by setting a WQEC bit on a WQE. The current driver sets it on every Nth WQE posting. However, the driver isn't clearing the bit if the WQE is reused. Thus, if the queue depth isn't evenly divisible by N, with enough time, it can be set on every element, creating a lot of overhead and risking CQ full conditions. Correct by clearing the bit when not setting it on an Nth element. Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <james.smart@broadcom.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
James Smart authored
[ Upstream commit 161df4f0 ] During link bounce testing in a point-to-point topology, the host may enter a soft lockup on the lpfc_worker thread: Call Trace: lpfc_work_done+0x1f3/0x1390 [lpfc] lpfc_do_work+0x16f/0x180 [lpfc] kthread+0xc7/0xe0 ret_from_fork+0x3f/0x70 The driver was simultaneously setting a combination of flags that caused lpfc_do_work()to effectively spin between slow path work and new event data, causing the lockup. Ensure in the typical wq completions, that new event data flags are set if the slow path flag is running. The slow path will eventually reschedule the wq handling. Signed-off-by:
-
James Smart authored
[ Upstream commit 2289e959 ] The driver ignored checks on whether the link should be kept administratively down after a link bounce. Correct the checks. Signed-off-by:
-
Richard Haines authored
[ Upstream commit 213d7f94 ] When resolving a fallback label, check the sk_buff version as it is possible (e.g. SCTP) to have family = PF_INET6 while receiving ip_hdr(skb)->version = 4. Signed-off-by:
Richard Haines <richard_c_haines@btinternet.com> Acked-by:
-
Prashant Bhole authored
[ Upstream commit ddd00103 ] eBPF test fails due to verifier failure because log_buf is too small. Fixed by increasing log_buf size Signed-off-by:
Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> Acked-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Jiri Olsa authored
[ Upstream commit e3ebaa46 ] Jin Yao reported memory corrupton in perf report with branch info used for stack trace: > Following command lines will cause perf crash. > perf record -j call -g -a <application> > perf report --branch-history > > *** Error in `perf': double free or corruption (!prev): 0x00000000104aa040 *** > ======= Backtrace: ========= > /lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7f6b37254725] > /lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7f6b3725cf4a] > /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f6b37260abc] > perf[0x51b914] > perf(hist_entry_iter__add+0x1e5)[0x51f305] > perf[0x43cf01] > perf[0x4fa3bf] > perf[0x4fa923] > perf[0x4fd396] > perf[0x4f9614] > perf(perf_session__process_events+0x89e)[0x4fc38e] > perf(cmd_report+0x15d2)[0x43f202] > perf[0x4a059f] > perf(main+0x631)[0x427b71] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f6b371fd830] > perf(_start+0x29)[0x427d89] For the cumulative output, we allocate the he_cache array based on the --max-stack option value and populate it with data from 'callchain_cursor'. The --max-stack option value does not ensure now the limit for number of callchain_cursor nodes, so the cumulative iter code will allocate smaller array than it's actually needed and cause above corruption. I think the --max-stack limit does not apply here anyway, because we add callchain data as normal hist entries, while the --max-stack control the limit of single entry callchain depth. Using the callchain_cursor.nr as he_cache array count to fix this. Also removing struct hist_entry_iter::max_stack, because there's no longer any use for it. We need more fixes to ensure that the branch stack code follows properly the logic of --max-stack, which is not the case at the moment. Original-patch-by:
Jin Yao <yao.jin@linux.intel.com> Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Reported-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
