- 14 May, 2019 40 commits
-
-
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:
Alexander Shishkin <alexander.shishkin@linux.intel.com> 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: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Namhyung Kim <namhyung@kernel.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/1453216469-9509-1-git-send-email-alexander.shishkin@linux.intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> 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>
-
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:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Nicolas Pitre authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 8d43b49e ] do_div() must only be used with a u64 dividend. Signed-off-by:
Nicolas Pitre <nico@linaro.org> Signed-off-by:
-
Christoph Lameter authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 0eb77e98 ] Currently the vmstat updater is not deferrable as a result of commit ba4877b9 ("vmstat: do not use deferrable delayed work for vmstat_update"). This in turn can cause multiple interruptions of the applications because the vmstat updater may run at Make vmstate_update deferrable again and provide a function that folds the differentials when the processor is going to idle mode thus addressing the issue of the above commit in a clean way. Note that the shepherd thread will continue scanning the differentials from another processor and will reenable the vmstat workers if it detects any changes. Fixes: ba4877b9 ("vmstat: do not use deferrable delayed work for vmstat_update") Signed-off-by:
Christoph Lameter <cl@linux.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dmitry Torokhov authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 699f6855 ] Using fence->status to determine whether or not there are callbacks remaining on the sync_fence is racy since fence->status may have been decremented to 0 on another CPU before fence_check_cb_func() has completed. By unconditionally calling fence_remove_callback() for each fence in the sync_fence, we guarantee that each callback has either completed (since fence_remove_callback() grabs the fence lock) or been removed. Signed-off-by:
Andrew Bresticker <abrestic@chromium.org> Signed-off-by:
Dmitry Torokhov <dtor@chromium.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Jungseung Lee authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit ad84f56b ] The VMSA field of MMFR0 (bottom 4 bits) is incremented for each added feature. PXN is supported if the value is >= 4 and LPAE is supported if it is >= 5. In case a kernel with CONFIG_ARM_LPAE disabled is used on a processor that supports LPAE, we can still use PXN in short descriptors. So check for >= 4 not == 4. Signed-off-by:
Jungseung Lee <js07.lee@samsung.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 6c044fec ] It is not possible to build the bL_switcher code if the GIC driver is disabled, because it relies on calling into some gic specific interfaces, and that would result in this build error: arch/arm/common/built-in.o: In function `bL_switch_to': :(.text+0x1230): undefined reference to `gic_get_sgir_physaddr' :(.text+0x1244): undefined reference to `gic_send_sgi' :(.text+0x1268): undefined reference to `gic_migrate_target' arch/arm/common/built-in.o: In function `bL_switcher_enable.part.4': :(.text.unlikely+0x2f8): undefined reference to `gic_get_cpu_id' This adds a Kconfig dependency to ensure we only build the big-little switcher if the GIC driver is present as well. Almost all ARMv7 platforms come with a GIC anyway, but it is possible to build a kernel that disables all platforms. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
-
Ard Biesheuvel authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit b523e185 ] This moves the DISABLE_BRANCH_PROFILING define from the x86 specific to the general CFLAGS definition for the stub. This fixes build errors when building for arm64 with CONFIG_PROFILE_ALL_BRANCHES_ENABLED. Reviewed-by:
Matt Fleming <matt@codeblueprint.co.uk> Reported-by:
-
Yury Norov authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit b9b7aebb ] ARM glibc uses (4 * __getpagesize()) for SHMLBA, which is correct for 4KB pages and works fine for 64KB pages, but the kernel uses a hardcoded 16KB that is too small for 64KB page based kernels. This changes the definition to what user space sees when using 64KB pages. Acked-by:
Yury Norov <ynorov@caviumnetworks.com> Signed-off-by:
-
Colin Cross authored
BugLink: https://bugs.launchpad.net/bugs/1826212 [ Upstream commit 382c55f8 ] It is quite common for Android devices to utilize more then 8 partitions on internal eMMC storage. The vanilla kernel can support this via CONFIG_MMC_BLOCK_MINORS, however that solution caps the system to 256 minors total, which limits the number of mmc cards the system can support. This patch, which has been carried for quite awhile in the AOSP common tree, provides an alternative solution that doesn't seem to limit the total card count. So I wanted to submit it for consideration upstream. This patch sets the GENHD_FL_EXT_DEVT flag, which will allocate minor number in major 259 for partitions past disk->minors. It also removes the use of disk_devt to determine devidx from md->disk. md->disk->first_minor is always initialized from devidx and can always be used to recover it. Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: Chuanxiao Dong <chuanxiao.dong@intel.com> Cc: Shawn Lin <shawn.lin@rock-chips.com> Cc: Austin S Hemmelgarn <ahferroin7@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Android Kernel Team <kernel-team@android.com> Cc: linux-mmc@vger.kernel.org Signed-off-by:
Colin Cross <ccross@android.com> [jstultz: Added context to commit message] Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 6707ba01 upstream. The way that 'strncat' is used here raised a warning in gcc-8: drivers/net/wireless/ath/ath10k/wmi.c: In function 'ath10k_wmi_tpc_stats_final_disp_tables': drivers/net/wireless/ath/ath10k/wmi.c:4649:4: error: 'strncat' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation] Effectively, this is simply a strcat() but the use of strncat() suggests some form of overflow check. Regardless of whether this might actually overflow, using strlcat() instead of strncat() avoids the warning and makes the code more robust. Fixes: bc64d052 ("ath10k: debugfs support to get final TPC stats for 10.4 variants") Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Baolin Wang authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 36d46cdb upstream. If we convert one large time values to rtc_time, in the original formula 'days * 86400' can be overflowed in 'unsigned int' type to make the formula get one incorrect remain seconds value. Thus we can use div_s64_rem() function to avoid this situation. Signed-off-by:
Baolin Wang <baolin.wang@linaro.org> Acked-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Andrey Konovalov authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 32fd87b3 upstream. When cleaning up the configurations, make sure we only free the number of configurations and interfaces that we could have allocated. Reported-by:
Andrey Konovalov <andreyknvl@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Peter Zijlstra authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 3f329570 upstream. The current int_sqrt() computation is sub-optimal for the case of small @x. Which is the interesting case when we're going to do cumulative distribution functions on idle times, which we assume to be a random variable, where the target residency of the deepest idle state gives an upper bound on the variable (5e6ns on recent Intel chips). In the case of small @x, the compute loop: while (m != 0) { b = y + m; y >>= 1; if (x >= b) { x -= b; y += m; } m >>= 2; } can be reduced to: while (m > x) m >>= 2; Because y==0, b==m and until x>=m y will remain 0. And while this is computationally equivalent, it runs much faster because there's less code, in particular less branches. cycles: branches: branch-misses: OLD: hot: 45.109444 +- 0.044117 44.333392 +- 0.002254 0.018723 +- 0.000593 cold: 187.737379 +- 0.156678 44.333407 +- 0.002254 6.272844 +- 0.004305 PRE: hot: 67.937492 +- 0.064124 66.999535 +- 0.000488 0.066720 +- 0.001113 cold: 232.004379 +- 0.332811 66.999527 +- 0.000488 6.914634 +- 0.006568 POST: hot: 43.633557 +- 0.034373 45.333132 +- 0.002277 0.023529 +- 0.000681 cold: 207.438411 +- 0.125840 45.333132 +- 0.002277 6.976486 +- 0.004219 Averages computed over all values <128k using a LFSR to generate order. Cold numbers have a LFSR based branch trace buffer 'confuser' ran between each int_sqrt() invocation. Link: http://lkml.kernel.org/r/20171020164644.876503355@infradead.org Fixes: 30493cc9 ("lib/int_sqrt.c: optimize square root algorithm") Signed-off-by:
Anshul Garg <aksgarg1989@gmail.com> Acked-by:
-
Lanqing Liu authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 43507825 upstream. On Spreadtrum's serial device, nearly all of interrupts would be cleared by hardware except timeout interrupt. This patch removed the operation of clearing all interrupt in irq handler, instead added an if statement to check if the timeout interrupt is supposed to be cleared. Wrongly clearing timeout interrupt would lead to uart data stay in rx fifo, that means the driver cannot read them out anymore. Signed-off-by:
Lanqing Liu <lanqing.liu@spreadtrum.com> Signed-off-by:
Chunyan Zhang <chunyan.zhang@spreadtrum.com> Signed-off-by:
-
Yoshihiro Shimoda authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit b7d44c36 upstream. The commit b8b9c974 ("usb: renesas_usbhs: gadget: disable all eps when the driver stops") causes the unused-but-set-variable warning. But, if the usbhsg_ep_disable() will return non-zero value, udc/core.c doesn't clear the ep->enabled flag. So, this driver should not return non-zero value, if the pipe is zero because this means the pipe is already disabled. Otherwise, the ep->enabled flag is never cleared when the usbhsg_ep_disable() is called by the renesas_usbhs driver first. Fixes: b8b9c974 ("usb: renesas_usbhs: gadget: disable all eps when the driver stops") Fixes: 11432050 ("usb: renesas_usbhs: gadget: fix NULL pointer dereference in ep_disable()") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Qiao Zhou authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 6f44a0ba upstream. In current die(), the irq is disabled for __die() handle, not including the possible panic() handling. Since the log in __die() can take several hundreds ms, new irq might come and interrupt current die(). If the process calling die() holds some critical resource, and some other process scheduled later also needs it, then it would deadlock. The first panic will not be executed. So here disable irq for the whole flow of die(). Signed-off-by:
Qiao Zhou <qiaozhou@asrmicro.com> Signed-off-by:
-
Al Viro authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 81be24d2 upstream. It's not hard to trigger a bunch of d_invalidate() on the same dentry in parallel. They end up fighting each other - any dentry picked for removal by one will be skipped by the rest and we'll go for the next iteration through the entire subtree, even if everything is being skipped. Morevoer, we immediately go back to scanning the subtree. The only thing we really need is to dissolve all mounts in the subtree and as soon as we've nothing left to do, we can just unhash the dentry and bugger off. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Wei Qiao authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit e1dc9b08 upstream. SPRD_TIMEOUT was 256, which is too small to wait until the status switched to workable in a while loop, so that the earlycon could not work correctly. Signed-off-by:
Wei Qiao <wei.qiao@spreadtrum.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 5ea8ea2c upstream. Per listen(fd, backlog) rules, there is really no point accepting a SYN, sending a SYNACK, and dropping the following ACK packet if accept queue is full, because application is not draining accept queue fast enough. This behavior is fooling TCP clients that believe they established a flow, while there is nothing at server side. They might then send about 10 MSS (if using IW10) that will be dropped anyway while server is under stress. Signed-off-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Acked-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Baolin Wang authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 511a36d2 upstream. When usb gadget is set gadget serial function, it will be crash in below situation. It will clean the 'port->port_usb' pointer in gserial_disconnect() function when usb link is inactive, but it will release lock for disabling the endpoints in this function. Druing the lock release period, it maybe complete one request to issue gs_write_complete()--->gs_start_tx() function, but the 'port->port_usb' pointer had been set NULL, thus it will be crash in gs_start_tx() function. This patch adds the 'port->port_usb' pointer checking in gs_start_tx() function to avoid this situation. Signed-off-by:
-
Peter Chen authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit c526c62d upstream. cdev->config is checked for null pointer at above code, so cdev->config might be null, fix it by adding null pointer check. Signed-off-by:
Peter Chen <peter.chen@nxp.com> Signed-off-by:
-
Wolfram Sang authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 78283edf upstream. I tried to use 'make O=...' from an unclean source tree. This triggered the error path of setlocalversion. But by printing to STDOUT, it created a broken localversion which then caused another (unrelated) error: "4.7.0-rc2Error: kernelrelease not valid - run make prepare to update it" exceeds 64 characters After printing to STDERR, the true build error gets displayed later: /home/wsa/Kernel/linux is not clean, please run 'make mrproper' in the '/home/wsa/Kernel/linux' directory. Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
Michal Marek <mmarek@suse.com> Signed-off-by:
-
Roger Quadros authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 04c08008 upstream. Pin state might have changed during suspend/resume while our interrupts were disabled and if device doesn't support wakeup. Scan for change during resume for such case. Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by:
-
Konstantin Khlebnikov authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit e4c5800a upstream. This check effectively catches anon vma hierarchy inconsistence and some vma corruptions. It was effective for catching corner cases in anon vma reusing logic. For now this code seems stable so check could be hidden under CONFIG_DEBUG_VM and replaced with WARN because it's not so fatal. Signed-off-by:
Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Suggested-by:
Vasily Averin <vvs@virtuozzo.com> Acked-by:
Vlastimil Babka <vbabka@suse.cz> Signed-off-by:
-
Dong Aisheng authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit e51534c8 upstream. Currently MMC core will keep going if HS200/HS timing switch failed with -EBADMSG error by the assumption that the old timing is still valid. However, for mmc_select_hs200 case, the signal voltage may have already been switched. If the timing switch failed, we should fall back to the old voltage in case the card is continue run with legacy timing. If fall back signal voltage failed, we explicitly report an EIO error to force retry during the next power cycle. Signed-off-by:
Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by:
-
James Morse authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 6afedcd2 upstream. With CONFIG_PROVE_LOCKING, CONFIG_DEBUG_LOCKDEP and CONFIG_TRACE_IRQFLAGS enabled, lockdep will compare current->hardirqs_enabled with the flags from local_irq_save(). When a debug exception occurs, interrupts are disabled in entry.S, but lockdep isn't told, resulting in: DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled) ------------[ cut here ]------------ WARNING: at ../kernel/locking/lockdep.c:3523 Modules linked in: CPU: 3 PID: 1752 Comm: perf Not tainted 4.5.0-rc4+ #2204 Hardware name: ARM Juno development board (r1) (DT) task: ffffffc974868000 ti: ffffffc975f40000 task.ti: ffffffc975f40000 PC is at check_flags.part.35+0x17c/0x184 LR is at check_flags.part.35+0x17c/0x184 pc : [<ffffff80080fc93c>] lr : [<ffffff80080fc93c>] pstate: 600003c5 [...] ---[ end trace 74631f9305ef5020 ]--- Call trace: [<ffffff80080fc93c>] check_flags.part.35+0x17c/0x184 [<ffffff80080ffe30>] lock_acquire+0xa8/0xc4 [<ffffff8008093038>] breakpoint_handler+0x118/0x288 [<ffffff8008082434>] do_debug_exception+0x3c/0xa8 [<ffffff80080854b4>] el1_dbg+0x18/0x6c [<ffffff80081e82f4>] do_filp_open+0x64/0xdc [<ffffff80081d6e60>] do_sys_open+0x140/0x204 [<ffffff80081d6f58>] SyS_openat+0x10/0x18 [<ffffff8008085d30>] el0_svc_naked+0x24/0x28 possible reason: unannotated irqs-off. irq event stamp: 65857 hardirqs last enabled at (65857): [<ffffff80081fb1c0>] lookup_mnt+0xf4/0x1b4 hardirqs last disabled at (65856): [<ffffff80081fb188>] lookup_mnt+0xbc/0x1b4 softirqs last enabled at (65790): [<ffffff80080bdca4>] __do_softirq+0x1f8/0x290 softirqs last disabled at (65757): [<ffffff80080be038>] irq_exit+0x9c/0xd0 This patch adds the annotations to do_debug_exception(), while trying not to call trace_hardirqs_off() if el1_dbg() interrupted a task that already had irqs disabled. Signed-off-by:
James Morse <james.morse@arm.com> Signed-off-by:
-
Roger Quadros authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 9772b47a upstream. Gadget controller might not be always active during system suspend/resume as gadget driver might not have yet been loaded or might have been unloaded prior to system suspend. Check if we're active and only then perform necessary actions during suspend/resume. Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 10a16a01 upstream. Each time a driver such as sdhci-esdhc-imx is probed, we get a info printk complaining that the DT voltage-ranges property has not been specified. However, the DT binding specifically says that the voltage-ranges property is optional. That means we should not be complaining that DT hasn't specified this property: by indicating that it's optional, it is valid not to have the property in DT. Silence the warning if the property is missing. Signed-off-by:
-
Wolfram Sang authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit ed9feec7 upstream. The bus width is sometimes the actual bus width, and sometimes indices to different arrays encoding the bus width. In my debugging case "2" could mean 8-bit as well as 4-bit, which was extremly confusing. Let's use the human-readable actual bus width in all places. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
-
Wolfram Sang authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 4ec96b4c upstream. IMO this info is only useful for developers. Most users won't need this information, since there is not much they can do about it. Signed-off-by:
-
Chuanxiao Dong authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit e5905ff1 upstream. Clock frequency values written to an mmc host should not be less than the minimum clock frequency which the mmc host supports. Signed-off-by:
Yuan Juntao <juntaox.yuan@intel.com> Signed-off-by:
Pawel Wodkowski <pawelx.wodkowski@intel.com> Signed-off-by:
-
Martin Fuzzey authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 64a67d47 upstream. The DT binding doc says reset-gpios is an optional property but the code currently bails out if it is omitted. This is a regression since it breaks previously working device trees. Fix it by restoring the original documented behaviour. Fixes: ce037275 ("mmc: pwrseq_simple: use GPIO descriptors array API") Tested-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Martin Fuzzey <mfuzzey@parkeon.com> Signed-off-by:
-
Hui Wang authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit b5a236c1 upstream. Recently we found the audio jack detection stop working after suspend on many machines with Realtek codec. Sometimes the audio selection dialogue didn't show up after users plugged headhphone/headset into the headset jack, sometimes after uses plugged headphone/headset, then click the sound icon on the upper-right corner of gnome-desktop, it also showed the speaker rather than the headphone. The root cause is that before suspend, the codec already call the runtime_suspend since this codec is not used by any apps, then in resume, it will not call runtime_resume for this codec. But for some realtek codec (so far, alc236, alc255 and alc891) with the specific BIOS, if it doesn't run runtime_resume after suspend, all codec functions including jack detection stop working anymore. This problem existed for a long time, but it was not exposed, that is because when problem happens, if users play sound or open sound-setting to check audio device, this will trigger calling to runtime_resume (via snd_hda_power_up), then the codec starts working again before users notice this problem. Since we don't know how many codec and BIOS combinations have this problem, to fix it, let the driver call runtime_resume for all codecs in pm_resume, maybe for some codecs, this is not needed, but it is harmless. After a codec is runtime resumed, if it is not used by any apps, it will be runtime suspended soon and furthermore we don't run suspend frequently, this change will not add much power consumption. Fixes: cc72da7d ("ALSA: hda - Use standard runtime PM for codec power-save control") Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 98081ca6 upstream. Currently we deal with single codec and suspend codec callbacks for all S3, S4 and runtime PM handling. But it turned out that we want distinguish the call patterns sometimes, e.g. for applying some init sequence only at probing and restoring from hibernate. This patch slightly modifies the common PM callbacks for HD-audio codec and stores the currently processed PM event in power_state of the codec's device.power field, which is currently unused. The codec callback can take a look at this event value and judges which purpose it's being called. Signed-off-by:
-
Waiman Long authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 71492580 upstream. Tetsuo Handa had reported he saw an incorrect "downgrading a read lock" warning right after a previous lockdep warning. It is likely that the previous warning turned off lock debugging causing the lockdep to have inconsistency states leading to the lock downgrade warning. Fix that by add a check for debug_locks at the beginning of __lock_downgrade(). Debugged-by:
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Reported-by:
Waiman Long <longman@redhat.com> Signed-off-by:
-
Hans Verkuil authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit f45f3f75 upstream. Control events can leak kernel memory since they do not fully zero the event. The same code is present in both v4l2-ctrls.c and uvc_ctrl.c, so fix both. It appears that all other event code is properly zeroing the structure, it's these two places. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Reported-by: syzbot+4f021cf3697781dbd9fb@syzkaller.appspotmail.com Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Sergei Shtylyov authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 5c27ff5d upstream. I have encountered an interrupt storm during the eMMC chip probing (and the chip finally didn't get detected). It turned out that U-Boot left the DMAC interrupts enabled while the Linux driver didn't use those. The SDHI driver's interrupt handler somehow assumes that, even if an SDIO interrupt didn't happen, it should return IRQ_HANDLED. I think that if none of the enabled interrupts happened and got handled, we should return IRQ_NONE -- that way the kernel IRQ code recoginizes a spurious interrupt and masks it off pretty quickly... Fixes: 7729c7a2 ("mmc: tmio: Provide separate interrupt handlers") Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Cc: stable@vger.kernel.org Signed-off-by:
-
zhangyi (F) authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 674a2b27 upstream. All indirect buffers get by ext4_find_shared() should be released no mater the branch should be freed or not. But now, we forget to release the lower depth indirect buffers when removing space from the same higher depth indirect block. It will lead to buffer leak and futher more, it may lead to quota information corruption when using old quota, consider the following case. - Create and mount an empty ext4 filesystem without extent and quota features, - quotacheck and enable the user & group quota, - Create some files and write some data to them, and then punch hole to some files of them, it may trigger the buffer leak problem mentioned above. - Disable quota and run quotacheck again, it will create two new aquota files and write the checked quota information to them, which probably may reuse the freed indirect block(the buffer and page cache was not freed) as data block. - Enable quota again, it will invoke vfs_load_quota_inode()->invalidate_bdev() to try to clean unused buffers and pagecache. Unfortunately, because of the buffer of quota data block is still referenced, quota code cannot read the up to date quota info from the device and lead to quota information corruption. This problem can be reproduced by xfstests generic/231 on ext3 file system or ext4 file system without extent and quota features. This patch fix this problem by releasing the missing indirect buffers, in ext4_ind_remove_space(). Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
zhangyi (F) <yi.zhang@huawei.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Reviewed-by:
Jan Kara <jack@suse.cz> Cc: stable@kernel.org Signed-off-by:
-
Lukas Czerner authored
BugLink: https://bugs.launchpad.net/bugs/1826212 commit 372a03e0 upstream. Ext4 needs to serialize unaligned direct AIO because the zeroing of partial blocks of two competing unaligned AIOs can result in data corruption. However it decides not to serialize if the potentially unaligned aio is past i_size with the rationale that no pending writes are possible past i_size. Unfortunately if the i_size is not block aligned and the second unaligned write lands past i_size, but still into the same block, it has the potential of corrupting the previous unaligned write to the same block. This is (very simplified) reproducer from Frank // 41472 = (10 * 4096) + 512 // 37376 = 41472 - 4096 ftruncate(fd, 41472); io_prep_pwrite(iocbs[0], fd, buf[0], 4096, 37376); io_prep_pwrite(iocbs[1], fd, buf[1], 4096, 41472); io_submit(io_ctx, 1, &iocbs[1]); io_submit(io_ctx, 1, &iocbs[2]); io_getevents(io_ctx, 2, 2, events, NULL); Without this patch the 512B range from 40960 up to the start of the second unaligned write (41472) is going to be zeroed overwriting the data written by the first write. This is a data corruption. 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 * 0000a000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 With this patch the data corruption is avoided because we will recognize the unaligned_aio and wait for the unwritten extent conversion. 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 * 0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 * 0000b200 Reported-by:
Frank Sorenson <fsorenso@redhat.com> Signed-off-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
-
