- 14 May, 2019 40 commits
-
-
Johannes Berg authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 4ef8c1c9 ] Ilan reported that sometimes nl80211 messages weren't working if the frames being transported got very large, which was really a problem for userspace-to-kernel messages, but prompted me to look at the code. Upon review, I found various places where variable-length data is transported in an nl80211 message but the message isn't allocated taking that into account. This shouldn't cause any problems since the frames aren't really that long, apart in one place where two (possibly very long frames) might not fit. Fix all the places (that I found) that get variable length data from the driver and put it into a message to take the length of the variable data into account. The 100 there is just a safe constant for the remaining message overhead (it's usually around 50 for most messages.) Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Chaotian Jing authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 987aa5f8 ] with CONFIG_HZ=100, the precision of jiffies is 10ms, and the generic_cmd6_time of some card is also 10ms. then, may be current time is only 5ms, but already timed out caused by jiffies precision. Signed-off-by:
Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Ezequiel Garcia authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 99a50777 ] The rtc-lib dependency is not required, and seems it was just copy-pasted from ARM's Kconfig. If platform requires rtc-lib, they should select it individually. Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Christoffer Dall authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit ace6033e ] User space Android code identifies pixclock == 0 as a sign for emulation and will set the frame rate to 60 fps when reading this value, which is the desired outcome. Signed-off-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
Peter Maydell <peter.maydell@linaro.org> Signed-off-by:
Roman Kiryanov <rkir@google.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Lianwei Wang authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 01b41159 ] When cpu_hotplug_enable() is called unbalanced w/o a preceeding cpu_hotplug_disable() the code emits a warning, but happily decrements the disabled counter. This causes the next operations to malfunction. Prevent the decrement and just emit a warning. Signed-off-by:
Lianwei Wang <lianwei.wang@gmail.com> Cc: peterz@infradead.org Cc: linux-pm@vger.kernel.org Cc: oleg@redhat.com Link: http://lkml.kernel.org/r/1465541008-12476-1-git-send-email-lianwei.wang@gmail.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Xerox Lin authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 207707d8 ] When rndis data transfer is in progress, some Windows7 Host PC is not sending the GET_ENCAPSULATED_RESPONSE command for receiving the response for the previous SEND_ENCAPSULATED_COMMAND processed. The rndis function driver appends each response for the SEND_ENCAPSULATED_COMMAND in a queue. As the above process got corrupted, the Host sends a REMOTE_NDIS_RESET_MSG command to do a soft-reset. As the rndis response queue is not freed, the previous response is sent as a part of this REMOTE_NDIS_RESET_MSG's reset response and the Host block any more Rndis transfers. Hence free the rndis response queue as a part of this soft-reset so that the correct response for REMOTE_NDIS_RESET_MSG is sent properly during the response command. Signed-off-by:
Rajkumar Raghupathy <raghup@codeaurora.org> Signed-off-by:
Xerox Lin <xerox_lin@htc.com> [AmitP: Cherry-picked this patch and folded other relevant fixes from Android common kernel android-4.4] Signed-off-by:
Amit Pundir <amit.pundir@linaro.org> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Winter Wang authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit cee51c33 ] There may be a race condition if f_fs calls unregister_gadget_item in ffs_closed() when unregister_gadget is called by UDC store at the same time. this leads to a kernel NULL pointer dereference: [ 310.644928] Unable to handle kernel NULL pointer dereference at virtual address 00000004 [ 310.645053] init: Service 'adbd' is being killed... [ 310.658938] pgd = c9528000 [ 310.662515] [00000004] *pgd=19451831, *pte=00000000, *ppte=00000000 [ 310.669702] Internal error: Oops: 817 [#1] PREEMPT SMP ARM [ 310.675211] Modules linked in: [ 310.678294] CPU: 0 PID: 1537 Comm: ->transport Not tainted 4.1.15-03725-g793404c #2 [ 310.685958] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 310.692493] task: c8e24200 ti: c945e000 task.ti: c945e000 [ 310.697911] PC is at usb_gadget_unregister_driver+0xb4/0xd0 [ 310.703502] LR is at __mutex_lock_slowpath+0x10c/0x16c [ 310.708648] pc : [<c075efc0>] lr : [<c0bfb0bc>] psr: 600f0113 <snip..> [ 311.565585] [<c075efc0>] (usb_gadget_unregister_driver) from [<c075e2b8>] (unregister_gadget_item+0x1c/0x34) [ 311.575426] [<c075e2b8>] (unregister_gadget_item) from [<c076fcc8>] (ffs_closed+0x8c/0x9c) [ 311.583702] [<c076fcc8>] (ffs_closed) from [<c07736b8>] (ffs_data_reset+0xc/0xa0) [ 311.591194] [<c07736b8>] (ffs_data_reset) from [<c07738ac>] (ffs_data_closed+0x90/0xd0) [ 311.599208] [<c07738ac>] (ffs_data_closed) from [<c07738f8>] (ffs_ep0_release+0xc/0x14) [ 311.607224] [<c07738f8>] (ffs_ep0_release) from [<c023e030>] (__fput+0x80/0x1d0) [ 311.614635] [<c023e030>] (__fput) from [<c014e688>] (task_work_run+0xb0/0xe8) [ 311.621788] [<c014e688>] (task_work_run) from [<c010afdc>] (do_work_pending+0x7c/0xa4) [ 311.629718] [<c010afdc>] (do_work_pending) from [<c010770c>] (work_pending+0xc/0x20) for functions using functionFS, i.e. android adbd will close /dev/usb-ffs/adb/ep0 when usb IO thread fails, but switch adb from on to off also triggers write "none" > UDC. These 2 operations both call unregister_gadget, which will lead to the panic above. add a mutex before calling unregister_gadget for api used in f_fs. Signed-off-by:
Winter Wang <wente.wang@nxp.com> Signed-off-by:
-
Hannes Frederic Sowa authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit dcb94b88 ] IPv6 ping socket error handler doesn't correctly convert the new 32 bit mtu to host endianness before using. Cc: Lorenzo Colitti <lorenzo@google.com> Fixes: 6d0bfe22 ("net: ipv6: Add IPv6 support to the ping socket.") Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by:
Lorenzo Colitti <lorenzo@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Alexander Shishkin authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 389b6699 ] Currently, stm_register_device() makes the device visible and then proceeds to initializing spinlocks and other properties, which leaves a window when the device can already be opened but is not yet fully operational. Fix this by reversing the initialization order. Reported-by:
Alan Cox <alan.cox@intel.com> Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Reviewed-by:
Laurent Fert <laurent.fert@intel.com> Signed-off-by:
-
Alexander Shishkin authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit cbe4a61d ] Currently, the error path of stm_register_device() forgets to unregister the chrdev. Fix this. Reported-by:
-
James Morse authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit f6cf0545 ] Some architectures require code written to memory as if it were data to be 'cleaned' from any data caches before the processor can fetch them as new instructions. During resume from hibernate, the snapshot code copies some pages directly, meaning these architectures do not get a chance to perform their cache maintenance. Modify the read and decompress code to call flush_icache_range() on all pages that are restored, so that the restored in-place pages are guaranteed to be executable on these architectures. Signed-off-by:
James Morse <james.morse@arm.com> Acked-by:
Pavel Machek <pavel@ucw.cz> Acked-by:
Rafael J. Wysocki <rjw@rjwysocki.net> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> [will: make clean_pages_on_* static and remove initialisers] Signed-off-by:
-
James Morse authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 81226455 ] page.h uses '_AC' in the definition of PAGE_SIZE, but doesn't include linux/const.h where this is defined. This produces build warnings when only asm/page.h is included by asm code. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Acked-by:
-
Alexander Shishkin authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit dcb10a96 ] When ring buffer's AUX area is unmapped and rb->aux_mmap_count drops to zero, new AUX transactions into this buffer can still be started, even though the buffer in en route to deallocation. This patch adds a check to perf_aux_output_begin() for rb->aux_mmap_count being zero, in which case there is no point starting new transactions, in other words, the ring buffers that pass a certain point in perf_mmap_close will not have their events sending new data, which clears path for freeing those buffers' pages right there and then, provided that no active transactions are holding the AUX reference. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: vince@deater.net Link: http://lkml.kernel.org/r/1457098969-21595-2-git-send-email-alexander.shishkin@linux.intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Jeff Mahoney authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit b4201cc4 ] This fixes: net/mac80211/mesh_hwmp.c:603:26: warning: ‘target_metric’ may be used uninitialized in this function target_metric is only consumed when reply = true so no bug exists here, but not all versions of gcc realize it. Initialize to 0 to remove the warning. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
-
Ard Biesheuvel authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit b660950c ] The implementation of macro inv_entry refers to its 'el' argument without the required leading backslash, which results in an undefined symbol 'el' to be passed into the kernel_entry macro rather than the index of the exception level as intended. This undefined symbol strangely enough does not result in build failures, although it is visible in vmlinux: $ nm -n vmlinux |head U el 0000000000000000 A _kernel_flags_le_hi32 0000000000000000 A _kernel_offset_le_hi32 0000000000000000 A _kernel_size_le_hi32 000000000000000a A _kernel_flags_le_lo32 ..... However, it does result in incorrect code being generated for invalid exceptions taken from EL0, since the argument check in kernel_entry assumes EL1 if its argument does not equal '0'. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
Lorenzo Pieralisi authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 1b9bdf5c ] The code enabled by the ARM_CPU_SUSPEND config option is used by kernel subsystems for purposes that go beyond system suspend so its config entry should be augmented to take more default options into account and avoid forcing its selection to prevent dependencies override. To achieve this goal, this patch reworks the ARM_CPU_SUSPEND config entry and updates its default config value (by adding the BL_SWITCHER option to it) and its dependencies (ARCH_SUSPEND_POSSIBLE), so that the symbol is still selected by default by the subsystems requiring it and at the same time enforcing the dependencies correctly. Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Nicolas Pitre <nico@fluxnic.net> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Greg Hackmann authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 45321507 ] We do actually need slab.h, by luck we get it on other platforms but not always on ARM. Include it properly. Signed-off-by:
Greg Hackmann <ghackmann@google.com> Signed-off-by:
Jin Qian <jinqian@android.com> Signed-off-by:
Alan <alan@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Rajmal Menariya authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 1328d8ef ] In carveout heap, change minimum allocation order from 12 to PAGE_SHIFT. After this change each bit in bitmap (genalloc - General purpose special memory pool) represents one page size memory. Cc: sprd-ind-kernel-group@googlegroups.com Cc: sanjeev.yadav@spreadtrum.com Cc: Colin Cross <ccross@android.com> Cc: Android Kernel Team <kernel-team@android.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by:
Rajmal Menariya <rajmal.menariya@spreadtrum.com> [jstultz: Reworked commit message] Signed-off-by:
John Stultz <john.stultz@linaro.org> Acked-by:
Laura Abbott <labbott@redhat.com> Signed-off-by:
-
Rom Lemarchand authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 90a2f171 ] Include <linux/types.h> into ashmem.h to ensure referenced types are defined Cc: Android Kernel Team <kernel-team@android.com> Cc: Greg KH <gregkh@linuxfoundation.org> Signed-off-by:
Rom Lemarchand <romlem@android.com> [jstultz: Minor commit message tweaks] Signed-off-by:
-
Laura Abbott authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 18e77054 ] Both ashmem_mmap and ashmem_shrink take the ashmem_lock. It may be possible for ashmem_mmap to invoke ashmem_shrink: -000|mutex_lock(lock = 0x0) -001|ashmem_shrink(?, sc = 0x0) <--- try to take ashmem_mutex again -002|shrink_slab(shrink = 0xDA5F1CC0, nr_pages_scanned = 0, lru_pages -002|= -002|124) -003|try_to_free_pages(zonelist = 0x0, ?, ?, ?) -004|__alloc_pages_nodemask(gfp_mask = 21200, order = 1, zonelist = -004|0xC11D0940, -005|new_slab(s = 0xE4841E80, ?, node = -1) -006|__slab_alloc.isra.43.constprop.50(s = 0xE4841E80, gfpflags = -006|2148925462, ad -007|kmem_cache_alloc(s = 0xE4841E80, gfpflags = 208) -008|shmem_alloc_inode(?) -009|alloc_inode(sb = 0xE480E800) -010|new_inode_pseudo(?) -011|new_inode(?) -012|shmem_get_inode(sb = 0xE480E800, dir = 0x0, ?, dev = 0, flags = -012|187) -013|shmem_file_setup(?, ?, flags = 187) -014|ashmem_mmap(?, vma = 0xC5D64210) <---- Acquire ashmem_mutex -015|mmap_region(file = 0xDF8E2C00, addr = 1772974080, len = 233472, -015|flags = 57, -016|sys_mmap_pgoff(addr = 0, len = 230400, prot = 3, flags = 1, fd = -016|157, pgoff -017|ret_fast_syscall(asm) -->|exception -018|NUR:0x40097508(asm) ---|end of frame Avoid this deadlock by using mutex_trylock in ashmem_shrink; if the mutex is already held, do not attempt to shrink. Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Android Kernel Team <kernel-team@android.com> Reported-by:
Matt Wagantall <mattw@codeaurora.org> Reported-by:
Syed Rameez Mustafa <rameezmustafa@codeaurora.org> Reported-by:
Osvaldo Banuelos <osvaldob@codeaurora.org> Reported-by:
Subbaraman Narayanamurthy <subbaram@codeaurora.org> Signed-off-by:
Laura Abbott <lauraa@codeaurora.org> [jstultz: Minor commit message tweaks] Signed-off-by:
-
Mark Rutland authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 3694bd76 ] Currently __set_fixmap_offset is a macro function which has a local variable called 'addr'. If a caller passes a 'phys' parameter which is derived from a variable also called 'addr', the local variable will shadow this, and the compiler will complain about the use of an uninitialized variable. To avoid the issue with namespace clashes, 'addr' is prefixed with a liberal sprinkling of underscores. Turning __set_fixmap_offset into a static inline breaks the build for several architectures. Fixing this properly requires updates to a number of architectures to make them agree on the prototype of __set_fixmap (it could be done as a subsequent patch series). Signed-off-by:
-
Eric Long authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 61390593 ] The dma_alloc_coherent return an "void *" not an "void __iomen *". It uses the wrong parameters when calls dma_free_coherent function. The sparse tool output logs as the following: coresight-tmc.c:199:23: expected void *<noident> coresight-tmc.c:199:23: got void [noderef] <asn:2>*vaddr coresight-tmc.c:336:30: warning: incorrect type in assignment (different address spaces) coresight-tmc.c:336:30: expected char *buf coresight-tmc.c:336:30: got void [noderef] <asn:2>* coresight-tmc.c:769:50: warning: incorrect type in argument 4 (different base types) coresight-tmc.c:769:50: expected unsigned long long [unsigned] [usertype] dma_handle coresight-tmc.c:769:50: got restricted gfp_t Signed-off-by:
Eric Long <eric.long@linaro.org> Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Eric Long authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit bf16e5b8 ] "DEVICE_ATTR_RO(name)" should be defined as static. And there is an unnecessary space at the front of the code. The sparse tool output logs as the following: coresight-etm4x.c:2224:1: warning: symbol 'dev_attr_trcoslsr' was not declared. Should it be static? coresight-etm4x.c:2225:1: warning: symbol 'dev_attr_trcpdcr' was not declared. Should it be static? coresight-etm4x.c:2226:1: warning: symbol 'dev_attr_trcpdsr' was not declared. Should it be static? And the smatch tool output logs as the following: of_coresight.c:89 of_coresight_alloc_memory() warn: inconsistent indenting Signed-off-by:
-
Alexander Shishkin authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit b4ca34aa ] There is a window in stm_source_link_drop(), during which the source's link may change before locks are acquired. When this happens, it throws a warning, since this is not an expected scenario. This patch handles the race in such a way that if the link appears to have changed by the time we took the locks, it will release them and repeat the whole unlinking procedure from the beginning, unless the other contender beat us to it. Signed-off-by:
-
Alexander Shishkin authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit f7c81c71 ] STM code takes references to the stm device and its module for the duration of the character device's existence or the stm_source link. Dropping these references is not well balanced everywhere, which may lead to leaks. This patch balances the acquisition and releasing of these two references and annotates each site so that it's easier to verify correctness by reading the code. Signed-off-by:
-
Alexander Shishkin authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit cde4ad83 ] It is possible to concurrently assign the same output (a character device writer or an stm_source device) to different stm devices, which sets off a strategically placed warning in stm_output_assign(). To avoid this, use a spinlock to serialize (un)assignments between outputs and stm devices. Signed-off-by:
-
Alexander Shishkin authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 1810f2c4 ] If an illegal attempt is made to unlink stm source device from an stm device, the stm device's link spinlock mistakenly remains locked. While this really shouldn't happen (there's a warning in place), the locking should remain in order so that we can still recover from this situation if it indeed does happen. This patch unifies the unlocking in the exit path of __stm_source_link_drop() to fix this. Reported-by:
-
Alexander Shishkin authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 59be422e ] By convention, the name of the stm policy directory in configfs consists of the device name to which it applies and the actual policy name, separated by a dot. Now, some devices already have dots in their names that separate name of the actual device from its instance identifier. Such devices will result in two (or more, who can tell) dots in the policy directory name. Existing policy code, however, will treat the first dot as the one that separates device name from policy name, therefore failing the above case. This patch makes the last dot in the directory name be the separator, thus prohibiting dots from being used in policy names. Suggested-by:
Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by:
-
Alexander Shishkin authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit f08b1826 ] Currently, the character device write method allocates a temporary buffer for user's data, but the user's data size is not sanitized and can cause arbitrarily large allocations via kzalloc() or an integer overflow that will then result in overwriting kernel memory. This patch trims the input buffer size to avoid these issues. Reported-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
-
Alexander Shishkin authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit c74f7e82 ] Currently, the list of stm_sources linked to an stm device is protected by a spinlock, which also means that sources' .unlink() method is called under this spinlock. However, this method may (and does) sleep, which means trouble. This patch slightly reworks locking around stm::link_list so that bits that might_sleep() are called with a mutex held instead. Modification of this list requires both mutex and spinlock to be held, while looking at the list can be done under either mutex or spinlock. Signed-off-by:
-
Alexander Shishkin authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 4c127fd1 ] Right now, if stm device removal has to unbind from a policy (that is, an stm device that has STP policy, gets removed), it will trigger a nested lock on the stm device's policy mutex. This patch fixes the problem by moving the locking from the policy unbinding to policy removal (configfs path), where it's actually needed; the other caller of the policy unbinding function already takes the mutex around the call. Signed-off-by:
-
Mathieu Poirier authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit ad725aee ] In function 'coresight_unregister()', all references to the csdev that is being taken away need to be removed from the topology. Otherwise building the next coresight path from source to sink may use memory that has been released. Signed-off-by:
-
Mathieu Poirier authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit f2dfab35 ] The reference count taken by function bus_find_device() needs to be released if a child device is found, something this patch is adding. Reported-by:
Rabin Vincent <rabin@rab.in> Signed-off-by:
-
Mathieu Poirier authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit fae54158 ] In its current form the code never frees csdev->refcnt allocated in coresight_register(). There is also a problem with csdev->conns that is freed before device_unregister() rather than in the device release function. This patch addresses both issues by moving kfree(csdev->conns) to coresight_device_release() and freeing csdev->refcnt, also in the same function. Reported-by:
-
Mathieu Poirier authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit a9ddc71f ] On some platform the following lockdep error occurs when doing simple manipulations: [ 23.197021] [ 23.198608] ====================================================== [ 23.205078] [ INFO: possible circular locking dependency detected ] [ 23.211639] 4.4.0-rc8-00025-gbbf360b #172 Not tainted [ 23.216918] ------------------------------------------------------- [ 23.223480] sh/858 is trying to acquire lock: [ 23.228057] (coresight_mutex){+.+.+.}, at: [<c0415d40>] coresight_enable+0x1c/0x1b4 [ 23.236206] [ 23.236206] but task is already holding lock: [ 23.242309] (s_active#52){++++.+}, at: [<c01d4b40>] kernfs_fop_write+0x5c/0x1c0 [ 23.250122] [ 23.250122] which lock already depends on the new lock. [ 23.250122] [ 23.258697] [ 23.258697] the existing dependency chain (in reverse order) is: [ 23.266510] -> #1 (s_active#52){++++.+}: [ 23.270843] [<c01d30ec>] __kernfs_remove+0x294/0x35c [ 23.276672] [<c01d3e44>] kernfs_remove_by_name_ns+0x44/0x8c [ 23.283172] [<c01d6318>] remove_files+0x3c/0x84 [ 23.288543] [<c01d66b4>] sysfs_remove_group+0x48/0x9c [ 23.294494] [<c01d6734>] sysfs_remove_groups+0x2c/0x3c [ 23.300506] [<c030b658>] device_remove_attrs+0x5c/0x74 [ 23.306549] [<c030c290>] device_del+0x110/0x218 [ 23.311950] [<c030c3c4>] device_unregister+0x2c/0x6c [ 23.317779] [<c04156d8>] coresight_unregister+0x30/0x40 [ 23.323883] [<c041a290>] etm_probe+0x228/0x2e8 [ 23.329193] [<c02bc760>] amba_probe+0xe4/0x160 [ 23.334503] [<c0310540>] driver_probe_device+0x23c/0x480 [ 23.340728] [<c0310820>] __driver_attach+0x9c/0xa0 [ 23.346374] [<c030e400>] bus_for_each_dev+0x70/0xa4 [ 23.352142] [<c030fcf4>] driver_attach+0x24/0x28 [ 23.357604] [<c030f86c>] bus_add_driver+0x1e0/0x278 [ 23.363372] [<c0310d48>] driver_register+0x80/0x100 [ 23.369110] [<c02bc508>] amba_driver_register+0x58/0x5c [ 23.375244] [<c0749514>] etm_driver_init+0x18/0x1c [ 23.380889] [<c0009918>] do_one_initcall+0xc4/0x20c [ 23.386657] [<c0715e7c>] kernel_init_freeable+0x160/0x208 [ 23.392974] [<c052d7fc>] kernel_init+0x18/0xf0 [ 23.398254] [<c0010850>] ret_from_fork+0x14/0x24 [ 23.403747] -> #0 (coresight_mutex){+.+.+.}: [ 23.408447] [<c008ed60>] lock_acquire+0xe4/0x210 [ 23.413909] [<c0530a30>] mutex_lock_nested+0x74/0x450 [ 23.419860] [<c0415d40>] coresight_enable+0x1c/0x1b4 [ 23.425689] [<c0416030>] enable_source_store+0x58/0x68 [ 23.431732] [<c030b358>] dev_attr_store+0x20/0x2c [ 23.437286] [<c01d55e8>] sysfs_kf_write+0x50/0x54 [ 23.442871] [<c01d4ba8>] kernfs_fop_write+0xc4/0x1c0 [ 23.448699] [<c015b60c>] __vfs_write+0x34/0xe4 [ 23.454040] [<c015bf38>] vfs_write+0x98/0x174 [ 23.459228] [<c015c7a8>] SyS_write+0x4c/0xa8 [ 23.464355] [<c00107c0>] ret_fast_syscall+0x0/0x1c [ 23.470031] [ 23.470031] other info that might help us debug this: [ 23.470031] [ 23.478393] Possible unsafe locking scenario: [ 23.478393] [ 23.484619] CPU0 CPU1 [ 23.489349] ---- ---- [ 23.494079] lock(s_active#52); [ 23.497497] lock(coresight_mutex); [ 23.503906] lock(s_active#52); [ 23.509918] lock(coresight_mutex); [ 23.513702] [ 23.513702] *** DEADLOCK *** [ 23.513702] [ 23.519897] 3 locks held by sh/858: [ 23.523529] #0: (sb_writers#7){.+.+.+}, at: [<c015ec38>] __sb_start_write+0xa8/0xd4 [ 23.531799] #1: (&of->mutex){+.+...}, at: [<c01d4b38>] kernfs_fop_write+0x54/0x1c0 [ 23.539916] #2: (s_active#52){++++.+}, at: [<c01d4b40>] kernfs_fop_write+0x5c/0x1c0 [ 23.548156] [ 23.548156] stack backtrace: [ 23.552734] CPU: 0 PID: 858 Comm: sh Not tainted 4.4.0-rc8-00025-gbbf360b #172 [ 23.560302] Hardware name: Generic OMAP4 (Flattened Device Tree) [ 23.566589] Backtrace: [ 23.569152] [<c00154d4>] (dump_backtrace) from [<c00156d0>] (show_stack+0x18/0x1c) [ 23.577087] r7:ed4b8570 r6:c0936400 r5:c07ae71c r4:00000000 [ 23.583038] [<c00156b8>] (show_stack) from [<c027e69c>] (dump_stack+0x98/0xc0) [ 23.590606] [<c027e604>] (dump_stack) from [<c008a750>] (print_circular_bug+0x21c/0x33c) [ 23.599090] r5:c0939d60 r4:c0936400 [ 23.602874] [<c008a534>] (print_circular_bug) from [<c008e370>] (__lock_acquire+0x1c98/0x1d88) [ 23.611877] r10:00000003 r9:c0fd7a5c r8:ed4b8550 r7:ed4b8570 r6:ed4b8000 r5:c0ff69e4 [ 23.620117] r4:c0936400 r3:ed4b8550 [ 23.623901] [<c008c6d8>] (__lock_acquire) from [<c008ed60>] (lock_acquire+0xe4/0x210) [ 23.632080] r10:00000000 r9:00000000 r8:60000013 r7:c07cb7b4 r6:00000001 r5:00000000 [ 23.640350] r4:00000000 [ 23.643005] [<c008ec7c>] (lock_acquire) from [<c0530a30>] (mutex_lock_nested+0x74/0x450) [ 23.651458] r10:ecc0bf80 r9:edbe7dcc r8:ed4b8000 r7:c0fd7a5c r6:c0415d40 r5:00000000 [ 23.659729] r4:c07cb780 [ 23.662384] [<c05309bc>] (mutex_lock_nested) from [<c0415d40>] (coresight_enable+0x1c/0x1b4) [ 23.671234] r10:ecc0bf80 r9:edbe7dcc r8:ed733c00 r7:00000000 r6:ed733c00 r5:00000002 [ 23.679473] r4:ed762140 [ 23.682128] [<c0415d24>] (coresight_enable) from [<c0416030>] (enable_source_store+0x58/0x68) [ 23.691070] r7:00000000 r6:ed733c00 r5:00000002 r4:ed762160 [ 23.697052] [<c0415fd8>] (enable_source_store) from [<c030b358>] (dev_attr_store+0x20/0x2c) [ 23.705780] r5:edbe7dc0 r4:c0415fd8 [ 23.709533] [<c030b338>] (dev_attr_store) from [<c01d55e8>] (sysfs_kf_write+0x50/0x54) [ 23.717834] r5:edbe7dc0 r4:c030b338 [ 23.721618] [<c01d5598>] (sysfs_kf_write) from [<c01d4ba8>] (kernfs_fop_write+0xc4/0x1c0) [ 23.730163] r7:00000000 r6:00000000 r5:00000002 r4:edbe7dc0 [ 23.736145] [<c01d4ae4>] (kernfs_fop_write) from [<c015b60c>] (__vfs_write+0x34/0xe4) [ 23.744323] r10:00000000 r9:ecc0a000 r8:c0010964 r7:ecc0bf80 r6:00000002 r5:c01d4ae4 [ 23.752593] r4:ee385a40 [ 23.755249] [<c015b5d8>] (__vfs_write) from [<c015bf38>] (vfs_write+0x98/0x174) [ 23.762908] r9:ecc0a000 r8:c0010964 r7:ecc0bf80 r6:000ab0d8 r5:00000002 r4:ee385a40 [ 23.771057] [<c015bea0>] (vfs_write) from [<c015c7a8>] (SyS_write+0x4c/0xa8) [ 23.778442] r8:c0010964 r7:00000002 r6:000ab0d8 r5:ee385a40 r4:ee385a40 [ 23.785522] [<c015c75c>] (SyS_write) from [<c00107c0>] (ret_fast_syscall+0x0/0x1c) [ 23.793457] r7:00000004 r6:00000001 r5:000ab0d8 r4:00000002 [ 23.799652] coresight-etb10 54162000.etb: ETB enabled [ 23.805084] coresight-funnel 54164000.funnel: FUNNEL inport 0 enabled [ 23.811859] coresight-replicator 44000000.ocp:replicator: REPLICATOR enabled [ 23.819335] coresight-funnel 54158000.funnel: FUNNEL inport 0 enabled [ 23.826110] coresight-etm3x 5414c000.ptm: ETM tracing enabled The locking in coresight_unregister() is not required as the only customers of the function are drivers themselves when an initialisation failure has been encoutered. Reported-by:
-
Tahsin Erdogan authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 3d65ae46 ] inode struct members that track cgroup writeback information should be reinitialized when inode gets allocated from kmem_cache. Otherwise, their values remain and get used by the new inode. Signed-off-by:
Tahsin Erdogan <tahsin@google.com> Acked-by:
Tejun Heo <tj@kernel.org> Fixes: d10c8095 ("writeback: implement foreign cgroup inode bdi_writeback switching") Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Ulf Hansson authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit a5ebb87d ] This reverts commit 829b6962. Revert this change as it causes a sysfs path to change and therefore introduces and ABI regression. More precisely Android's vold is not being able to access /sys/module/mmcblk/parameters/perdev_minors any more, since the path becomes changed to: "/sys/module/mmc_block/..." Fixes: 829b6962 ("mmc: block: don't use parameter prefix if built as module") Reported-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 7c130672 ] Lorenzo reported that we could not properly find v4mapped sockets in inet_diag_find_one_icsk(). This patch fixes the issue. Reported-by:
Eric Dumazet <edumazet@google.com> Acked-by:
-
Alexander Shishkin authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 45c815f0 ] We are currently using asynchronous deallocation in the error path in AUX mmap code, which is unnecessary and also presents a problem for users that wish to probe for the biggest possible buffer size they can get: they'll get -EINVAL on all subsequent attemts to allocate a smaller buffer before the asynchronous deallocation callback frees up the pages from the previous unsuccessful attempt. Currently, gdb does that for allocating AUX buffers for Intel PT traces. More specifically, overwrite mode of AUX pmus that don't support hardware sg (some implementations of Intel PT, for instance) is limited to only one contiguous high order allocation for its buffer and there is no way of knowing its size without trying. This patch changes error path freeing to be synchronous as there won't be any contenders for the AUX pages at that point. Reported-by:
Markus Metzger <markus.t.metzger@intel.com> Signed-off-by:
-
Ard Biesheuvel authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 75feee3d ] Commit e8f3010f ("arm64/efi: isolate EFI stub from the kernel proper") isolated the EFI stub code from the kernel proper by prefixing all of its symbols with __efistub_, and selectively allowing access to core kernel symbols from the stub by emitting __efistub_ aliases for functions and variables that the stub can access legally. As an unintended side effect, these aliases are emitted into the kallsyms symbol table, which means they may turn up in backtraces, e.g., ... PC is at __efistub_memset+0x108/0x200 LR is at fixup_init+0x3c/0x48 ... [<ffffff8008328608>] __efistub_memset+0x108/0x200 [<ffffff8008094dcc>] free_initmem+0x2c/0x40 [<ffffff8008645198>] kernel_init+0x20/0xe0 [<ffffff8008085cd0>] ret_from_fork+0x10/0x40 The backtrace in question has nothing to do with the EFI stub, but simply returns one of the several aliases of memset() that have been recorded in the kallsyms table. This is undesirable, since it may suggest to people who are not aware of this that the issue they are seeing is somehow EFI related. So hide the __efistub_ aliases from kallsyms, by emitting them as absolute linker symbols explicitly. The distinction between those and section relative symbols is completely irrelevant to these definitions, and to the final link we are performing when these definitions are being taken into account (the distinction is only relevant to symbols defined inside a section definition when performing a partial link), and so the resulting values are identical to the original ones. Since absolute symbols are ignored by kallsyms, this will result in these values to be omitted from its symbol table. After this patch, the backtrace generated from the same address looks like this: ... PC is at __memset+0x108/0x200 LR is at fixup_init+0x3c/0x48 ... [<ffffff8008328608>] __memset+0x108/0x200 [<ffffff8008094dcc>] free_initmem+0x2c/0x40 [<ffffff8008645198>] kernel_init+0x20/0xe0 [<ffffff8008085cd0>] ret_from_fork+0x10/0x40 Signed-off-by:
-
