- 30 Jun, 2020 40 commits
-
-
Boris Brezillon authored
[ Upstream commit 59ac276f ] Let's make the raw NAND API consistent by patching all helpers to take a nand_chip object instead of an mtd_info one. Now is nand_release()'s turn. Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Mauro Carvalho Chehab authored
commit 330dada5 upstream The correct error code when a function is not defined is -ENOTSUPP. It was typoed wrong as -EOPNOTSUPP, with, unfortunately, exists, but it is not used by the DVB core. Thanks-to: Geert Uytterhoeven <geert@linux-m68k.org> Thanks-to: Arnd Bergmann <arnd@arndb.de> To make me revisit this code. Fixes: a9cb97c3 ("media: dvb_frontend: be sure to init dvb_frontend_handle_ioctl() return code") Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Katsuhiro Suzuki authored
commit 5c6c9c48 upstream FE_GET_PROPERTY has always failed as following situations: - Use compatible ioctl - The array of 'struct dtv_property' has 2 or more items This patch fixes wrong cast to a pointer 'struct dtv_property' from a pointer of 2nd or after item of 'struct compat_dtv_property' array. Signed-off-by:
Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com> Signed-off-by:
-
Jaedon Shin authored
commit 18192a77 upstream The dtv_properties structure and the dtv_property structure are different sizes in 32-bit and 64-bit system. This patch provides FE_SET_PROPERTY and FE_GET_PROPERTY ioctl commands implementation for 32-bit user space applications. Signed-off-by:
Jaedon Shin <jaedon.shin@gmail.com> Signed-off-by:
-
Jaedon Shin authored
commit c2dfd227 upstream Adds compat_ioctl for 32-bit user space applications on a 64-bit system. [m.chehab@osg.samsung.com: add missing include compat.h] Signed-off-by:
-
Jaedon Shin authored
commit a2282fd1 upstream Adds unlocked ioctl function directly in dvb_frontend.c instead of using dvb_generic_ioctl(). Signed-off-by:
-
Mauro Carvalho Chehab authored
commit a9cb97c3 upstream As smatch warned: drivers/media/dvb-core/dvb_frontend.c:2468 dvb_frontend_handle_ioctl() error: uninitialized symbol 'err'. The ioctl handler actually got a regression here: before changeset d73dcf0c ("media: dvb_frontend: cleanup ioctl handling logic"), the code used to return -EOPNOTSUPP if an ioctl handler was not implemented on a driver. After the change, it may return a random value. Fixes: d73dcf0c ("media: dvb_frontend: cleanup ioctl handling logic") Cc: stable@vger.kernel.org Signed-off-by:
Daniel Scheller <d.scheller@gmx.net> Signed-off-by:
-
Satendra Singh Thakur authored
commit media: dvb_frontend: dtv_property_process_set() cleanups upstream Since all properties in the func dtv_property_process_set() use at most 4 bytes arguments, change the code to pass u32 cmd and u32 data as function arguments, instead of passing a pointer to the entire struct dtv_property *tvp. Instead of having a generic dtv_property_dump(), added its own properties debug logic in the dtv_property_process_set(). Signed-off-by:
Satendra Singh Thakur <satendra.t@samsung.com> Reviewed-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 259a41d9 upstream There are several problems with regards to the return of FE_SET_PROPERTY. The original idea were to return per-property return codes via tvp->result field, and to return an updated set of values. However, that never worked. What's actually implemented is: - the FE_SET_PROPERTY implementation doesn't call .get_frontend callback in order to get the actual parameters after return; - the tvp->result field is only filled if there's no error. So, it is always filled with zero; - FE_SET_PROPERTY doesn't call memdup_user() nor any other copy_to_user() function. So, any changes to the properties will be lost; - FE_SET_PROPERTY is declared as a write-only ioctl (IOW). While we could fix the above, it could cause regressions. So, let's just assume what the code really does, updating the documentation accordingly and removing the logic that would update the discarded tvp->result. Reviewed-by:
-
Mauro Carvalho Chehab authored
commit da5516b5 upstream Two readonly ioctls can't be allowed if the frontend device is opened in read only mode. Explain why. Reviewed by: Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit ef2cc27c upstream In the past, I guess the idea was to use state in order to allow an autofush logic. However, in the current code, it is used only for debug messages, on a poor man's solution, as there's already a debug message to indicate when the properties got flushed. So, just get rid of it for good. Reviewed-by:
Shuah Khan <shuahkg@osg.samsung.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit d73dcf0c upstream Currently, there are two handlers for ioctls: - dvb_frontend_ioctl_properties() - dvb_frontend_ioctl_legacy() Despite their names, both handles non-legacy DVB ioctls. Besides that, there's no reason why to not handle all ioctls on a single handler function. So, merge them into a single function (dvb_frontend_handle_ioctl) and reorganize the ioctl's to indicate what's the current DVB API and what's deprecated. Despite the big diff, the handling logic for each ioctl is the same as before. Reviewed-by:
-
Mauro Carvalho Chehab authored
commit 2b5df42b upstream Use a switch() on this function, just like on other ioctl handlers and handle parameters inside each part of the switch. That makes it easier to integrate with the already existing ioctl handler function. Reviewed-by:
-
Mauro Carvalho Chehab authored
commit 6680e73b upstream Now that all clients of set_property() were removed, get rid of this callback. Signed-off-by:
-
Mauro Carvalho Chehab authored
commit b2c41ca9 upstream This callback is not actually doing anything but making it to return an error depending on the DTV frontend command. Well, that could break userspace for no good reason, and, if needed, should be implemented, instead, at set_frontend() callback. So, get rid of it. Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 28299692 upstream The stv6110 has a weird code that checks if get_property and set_property ioctls are defined. If they're, it initializes a "srate" var from properties cache. Otherwise, it sets to 15MBaud, with won't make any sense. Thankfully, it seems that someone else discovered the issue in the past, as "srate" is currently not used anywhere! So, get rid of that really weird dead code logic. Reported-by:
Honza Petrous <jpetrous@gmail.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 473e4b4c upstream This driver doesn't implement support for set_property(). Yet, it implements a boilerplate for it. Get rid of it. Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 8f8a19fc upstream Only lg2160 implement gets_property, but there's no need for that, as no other driver calls this callback, as get_frontend() does the same, and set_frontend() also calls lg2160 get_frontend(). So, get rid of it. Signed-off-by:
Michael Ira Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 8220ead8 upstream Most of the stuff at the Digital TV frontend header file are documented only at the Documentation. However, a few kernel-doc markups are there, several of them with parsing issues. Add the missing documentation, copying definitions from the Documentation when it applies, fixing some bugs. Please notice that DVBv3 stuff that were deprecated weren't commented by purpose. Instead, they were clearly tagged as such. This patch prepares to move part of the documentation from Documentation/ to kernel-doc comments. Signed-off-by:
-
Mauro Carvalho Chehab authored
commit f35afa4f upstream struct dtv_cmds_h is just an ancillary struct used by the dvb_frontend.c to internally store frontend commands. It doesn't belong to the userspace header, nor it is used anywhere, except inside the DVB core. So, remove it from the header. Signed-off-by:
-
Colin Ian King authored
commit 450694c3 upstream. GIT_AUTHOR_NAME=Colin King GIT_AUTHOR_EMAIL=colin.king@canonical.com In a previous commit, we added FE_NONE as an unknown fe_status. Initialize variable s to FE_NONE instead of the more opaque value 0. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
Ahmed S. Darwish authored
[ Upstream commit 11d6011c ] Sequence counters write paths are critical sections that must never be preempted, and blocking, even for CONFIG_PREEMPTION=n, is not allowed. Commit 5dbe7c17 ("net: fix kernel deadlock with interface rename and netdev name retrieval.") handled a deadlock, observed with CONFIG_PREEMPTION=n, where the devnet_rename seqcount read side was infinitely spinning: it got scheduled after the seqcount write side blocked inside its own critical section. To fix that deadlock, among other issues, the commit added a cond_resched() inside the read side section. While this will get the non-preemptible kernel eventually unstuck, the seqcount reader is fully exhausting its slice just spinning -- until TIF_NEED_RESCHED is set. The fix is also still broken: if the seqcount reader belongs to a real-time scheduling policy, it can spin forever and the kernel will livelock. Disabling preemption over the seqcount write side critical section will not work: inside it are a number of GFP_KERNEL allocations and mutex locking through the drivers/base/ :: device_rename() call chain. >From all the above, replace the seqcount with a rwsem. Fixes: 5dbe7c17 (net: fix kernel deadlock with interface rename and netdev name retrieval.) Fixes: 30e6c9fa (net: devnet_rename_seq should be a seqcount) Fixes: c91f6df2 (sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name) Cc: <stable@vger.kernel.org> Reported-by: kbuild test robot <lkp@intel.com> [ v1 missing up_read() on error exit ] Reported-by: Dan Carpenter <dan.carpenter@oracle.com> [ v1 missing up_read() on error exit ] Signed-off-by:
Ahmed S. Darwish <a.darwish@linutronix.de> Reviewed-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Thomas Gleixner authored
[ Upstream commit 2da2b32f ] CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT. Both PREEMPT and PREEMPT_RT require the same functionality which today depends on CONFIG_PREEMPT. Update the comment to use CONFIG_PREEMPTION. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Chen Yu authored
[ Upstream commit 6bf6be11 ] Currently the system will be woken up via WOL(Wake On LAN) even if the device wakeup ability has been disabled via sysfs: cat /sys/devices/pci0000:00/0000:00:1f.6/power/wakeup disabled The system should not be woken up if the user has explicitly disabled the wake up ability for this device. This patch clears the WOL ability of this network device if the user has disabled the wake up ability in sysfs. Fixes: bc7f75fa ("[E1000E]: New pci-express e1000 driver") Reported-by:
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
Chen Yu <yu.c.chen@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Jiri Olsa authored
[ Upstream commit 9b38cc70 ] Ziqian reported lockup when adding retprobe on _raw_spin_lock_irqsave. My test was also able to trigger lockdep output: ============================================ WARNING: possible recursive locking detected 5.6.0-rc6+ #6 Not tainted -------------------------------------------- sched-messaging/2767 is trying to acquire lock: ffffffff9a492798 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_hash_lock+0x52/0xa0 but task is already holding lock: ffffffff9a491a18 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_trampoline+0x0/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(kretprobe_table_locks[i].lock)); lock(&(kretprobe_table_locks[i].lock)); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by sched-messaging/2767: #0: ffffffff9a491a18 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_trampoline+0x0/0x50 stack backtrace: CPU: 3 PID: 2767 Comm: sched-messaging Not tainted 5.6.0-rc6+ #6 Call Trace: dump_stack+0x96/0xe0 __lock_acquire.cold.57+0x173/0x2b7 ? native_queued_spin_lock_slowpath+0x42b/0x9e0 ? lockdep_hardirqs_on+0x590/0x590 ? __lock_acquire+0xf63/0x4030 lock_acquire+0x15a/0x3d0 ? kretprobe_hash_lock+0x52/0xa0 _raw_spin_lock_irqsave+0x36/0x70 ? kretprobe_hash_lock+0x52/0xa0 kretprobe_hash_lock+0x52/0xa0 trampoline_handler+0xf8/0x940 ? kprobe_fault_handler+0x380/0x380 ? find_held_lock+0x3a/0x1c0 kretprobe_trampoline+0x25/0x50 ? lock_acquired+0x392/0xbc0 ? _raw_spin_lock_irqsave+0x50/0x70 ? __get_valid_kprobe+0x1f0/0x1f0 ? _raw_spin_unlock_irqrestore+0x3b/0x40 ? finish_task_switch+0x4b9/0x6d0 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 The code within the kretprobe handler checks for probe reentrancy, so we won't trigger any _raw_spin_lock_irqsave probe in there. The problem is in outside kprobe_flush_task, where we call: kprobe_flush_task kretprobe_table_lock raw_spin_lock_irqsave _raw_spin_lock_irqsave where _raw_spin_lock_irqsave triggers the kretprobe and installs kretprobe_trampoline handler on _raw_spin_lock_irqsave return. The kretprobe_trampoline handler is then executed with already locked kretprobe_table_locks, and first thing it does is to lock kretprobe_table_locks ;-) the whole lockup path like: kprobe_flush_task kretprobe_table_lock raw_spin_lock_irqsave _raw_spin_lock_irqsave ---> probe triggered, kretprobe_trampoline installed ---> kretprobe_table_locks locked kretprobe_trampoline trampoline_handler kretprobe_hash_lock(current, &head, &flags); <--- deadlock Adding kprobe_busy_begin/end helpers that mark code with fake probe installed to prevent triggering of another kprobe within this code. Using these helpers in kprobe_flush_task, so the probe recursion protection check is hit and the probe is never set to prevent above lockup. Link: http://lkml.kernel.org/r/158927059835.27680.7011202830041561604.stgit@devnote2 Fixes: ef53d9c5 ("kprobes: improve kretprobe scalability with hashed locking") Cc: Ingo Molnar <mingo@kernel.org> Cc: "Gustavo A . R . Silva" <gustavoars@kernel.org> Cc: Anders Roxell <anders.roxell@linaro.org> Cc: "Naveen N . Rao" <naveen.n.rao@linux.ibm.com> Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Cc: David Miller <davem@davemloft.net> Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <peterz@infradead.org> Cc: stable@vger.kernel.org Reported-by:
"Ziqian SUN (Zamir)" <zsun@redhat.com> Acked-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Masami Hiramatsu authored
[ Upstream commit b191fa96 ] Avoid kretprobe recursion loop bg by setting a dummy kprobes to current_kprobe per-CPU variable. This bug has been introduced with the asm-coded trampoline code, since previously it used another kprobe for hooking the function return placeholder (which only has a nop) and trampoline handler was called from that kprobe. This revives the old lost kprobe again. With this fix, we don't see deadlock anymore. And you can see that all inner-called kretprobe are skipped. event_1 235 0 event_2 19375 19612 The 1st column is recorded count and the 2nd is missed count. Above shows (event_1 rec) + (event_2 rec) ~= (event_2 missed) (some difference are here because the counter is racy) Reported-by:
Andrea Righi <righi.andrea@gmail.com> Tested-by:
-
Naveen N. Rao authored
[ Upstream commit 30176466 ] Fix two issues with kprobes.h on BE which were exposed with the optprobes work: - one, having to do with a missing include for linux/module.h for MODULE_NAME_LEN -- this didn't show up previously since the only users of kprobe_lookup_name were in kprobes.c, which included linux/module.h through other headers, and - two, with a missing const qualifier for a local variable which ends up referring a string literal. Again, this is unique to how kprobe_lookup_name is being invoked in optprobes.c Signed-off-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Masami Hiramatsu authored
[ Upstream commit 1a0aa991 ] In kprobe_optimizer() kick_kprobe_optimizer() is called without kprobe_mutex, but this can race with other caller which is protected by kprobe_mutex. To fix that, expand kprobe_mutex protected area to protect kick_kprobe_optimizer() call. Link: http://lkml.kernel.org/r/158927057586.27680.5036330063955940456.stgit@devnote2 Fixes: cd7ebe22 ("kprobes: Use text_poke_smp_batch for optimizing") Cc: Ingo Molnar <mingo@kernel.org> Cc: "Gustavo A . R . Silva" <gustavoars@kernel.org> Cc: Anders Roxell <anders.roxell@linaro.org> Cc: "Naveen N . Rao" <naveen.n.rao@linux.ibm.com> Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Cc: David Miller <davem@davemloft.net> Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ziqian SUN <zsun@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Eric Biggers authored
commit 77251e41 upstream. When a crypto template needs to be instantiated, CRYPTO_MSG_ALG_REQUEST is sent to crypto_chain. cryptomgr_schedule_probe() handles this by starting a thread to instantiate the template, then waiting for this thread to complete via crypto_larval::completion. This can deadlock because instantiating the template may require loading modules, and this (apparently depending on userspace) may need to wait for the crc-t10dif module (lib/crc-t10dif.c) to be loaded. But crc-t10dif's module_init function uses crypto_register_notifier() and therefore takes crypto_chain.rwsem for write. That can't proceed until the notifier callback has finished, as it holds this semaphore for read. Fix this by removing the wait on crypto_larval::completion from within cryptomgr_schedule_probe(). It's actually unnecessary because crypto_alg_mod_lookup() calls crypto_larval_wait() itself after sending CRYPTO_MSG_ALG_REQUEST. This only actually became a problem in v4.20 due to commit b7637754 ("crc-t10dif: Pick better transform if one becomes available"), but the unnecessary wait was much older. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207159Reported-by:
Mike Gerow <gerow@google.com> Fixes: 39871037 ("crypto: algapi - Move larval completion into algboss") Cc: <stable@vger.kernel.org> # v3.6+ Cc: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Eric Biggers <ebiggers@google.com> Reported-by:
Kai Lüke <kai@kinvolk.io> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Chris Wilson authored
commit 273500ae upstream. Allow batch buffers to read their own _local_ cumulative HW runtime of their logical context. Fixes: 0f2f3975 ("drm/i915: Add gen9 BCS cmdparsing") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.4+ Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200601161942.30854-1-chris@chris-wilson.co.uk (cherry picked from commit f9496520) Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Dmitry V. Levin authored
commit b3583fca upstream. If both the tracer and the tracee are compat processes, and gprs[2] is assigned a value by __poke_user_compat, then the higher 32 bits of gprs[2] are cleared, IS_ERR_VALUE() always returns false, and syscall_get_error() always returns 0. Fix the implementation by sign-extending the value for compat processes the same way as x86 implementation does. The bug was exposed to user space by commit 201766a2 ("ptrace: add PTRACE_GET_SYSCALL_INFO request") and detected by strace test suite. This change fixes strace syscall tampering on s390. Link: https://lkml.kernel.org/r/20200602180051.GA2427@altlinux.org Fixes: 753c4dd6 ("[S390] ptrace changes") Cc: Elvira Khabirova <lineprinter@altlinux.org> Cc: stable@vger.kernel.org # v2.6.28+ Signed-off-by:
Dmitry V. Levin <ldv@altlinux.org> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
-
Ahmed S. Darwish authored
[ Upstream commit 15b81ce5 ] For optimized block readers not holding a mutex, the "number of sectors" 64-bit value is protected from tearing on 32-bit architectures by a sequence counter. Disable preemption before entering that sequence counter's write side critical section. Otherwise, the read side can preempt the write side section and spin for the entire scheduler tick. If the reader belongs to a real-time scheduling class, it can spin forever and the kernel will livelock. Fixes: c83f6bf9 ("block: add partition resize function to blkpg ioctl") Cc: <stable@vger.kernel.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Ard Biesheuvel authored
commit bc310baf upstream. The final build stage of the x86 kernel captures some symbol addresses from the decompressor binary and copies them into zoffset.h. It uses sed with a regular expression that matches the address, symbol type and symbol name, and mangles the captured addresses and the names of symbols of interest into #define directives that are added to zoffset.h The symbol type is indicated by a single letter, which we match strictly: only letters in the set 'ABCDGRSTVW' are matched, even though the actual symbol type is relevant and therefore ignored. Commit bc7c9d62 ("efi/libstub/x86: Force 'hidden' visibility for extern declarations") made a change to the way external symbol references are classified, resulting in 'startup_32' now being emitted as a hidden symbol. This prevents the use of GOT entries to refer to this symbol via its absolute address, which recent toolchains (including Clang based ones) already avoid by default, making this change a no-op in the majority of cases. However, as it turns out, the LLVM linker classifies such hidden symbols as symbols with static linkage in fully linked ELF binaries, causing tools such as NM to output a lowercase 't' rather than an upper case 'T' for the type of such symbols. Since our sed expression only matches upper case letters for the symbol type, the line describing startup_32 is disregarded, resulting in a build error like the following arch/x86/boot/header.S:568:18: error: symbol 'ZO_startup_32' can not be undefined in a subtraction expression init_size: .long (0x00000000008fd000 - ZO_startup_32 + (((0x0000000001f6361c + ((0x0000000001f6361c >> 8) + 65536) - 0x00000000008c32e5) + 4095) & ~4095)) # kernel initialization size Given that we are only interested in the value of the symbol, let's match any character in the set 'a-zA-Z' instead. Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Lyude Paul authored
[ Upstream commit 873a95e0 ] Currently we only poll for an ACT up to 30 times, with a busy-wait delay of 100µs between each attempt - giving us a timeout of 2900µs. While this might seem sensible, it would appear that in certain scenarios it can take dramatically longer then that for us to receive an ACT. On one of the EVGA MST hubs that I have available, I observed said hub sometimes taking longer then a second before signalling the ACT. These delays mostly seem to occur when previous sideband messages we've sent are NAKd by the hub, however it wouldn't be particularly surprising if it's possible to reproduce times like this simply by introducing branch devices with large LCTs since payload allocations have to take effect on every downstream device up to the payload's target. So, instead of just retrying 30 times we poll for the ACT for up to 3ms, and additionally use usleep_range() to avoid a very long and rude busy-wait. Note that the previous retry count of 30 appears to have been arbitrarily chosen, as I can't find any mention of a recommended timeout or retry count for ACTs in the DisplayPort 2.0 specification. This also goes for the range we were previously using for udelay(), although I suspect that was just copied from the recommended delay for link training on SST devices. Changes since v1: * Use readx_poll_timeout() instead of open-coding timeout loop - Sean Paul Changes since v2: * Increase poll interval to 200us - Sean Paul * Print status in hex when we timeout waiting for ACT - Sean Paul Signed-off-by:
Lyude Paul <lyude@redhat.com> Fixes: ad7f8a1f ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Sean Paul <sean@poorly.run> Cc: <stable@vger.kernel.org> # v3.17+ Reviewed-by:
Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200406221253.1307209-4-lyude@redhat.comSigned-off-by:
-
Jeffle Xu authored
[ Upstream commit cfb3c85a ] Fix the bug when calculating the physical block number of the first block in the split extent. This bug will cause xfstests shared/298 failure on ext4 with bigalloc enabled occasionally. Ext4 error messages indicate that previously freed blocks are being freed again, and the following fsck will fail due to the inconsistency of block bitmap and bg descriptor. The following is an example case: 1. First, Initialize a ext4 filesystem with cluster size '16K', block size '4K', in which case, one cluster contains four blocks. 2. Create one file (e.g., xxx.img) on this ext4 filesystem. Now the extent tree of this file is like: ... 36864:[0]4:220160 36868:[0]14332:145408 51200:[0]2:231424 ... 3. Then execute PUNCH_HOLE fallocate on this file. The hole range is like: .. ext4_ext_remove_space: dev 254,16 ino 12 since 49506 end 49506 depth 1 ext4_ext_remove_space: dev 254,16 ino 12 since 49544 end 49546 depth 1 ext4_ext_remove_space: dev 254,16 ino 12 since 49605 end 49607 depth 1 ... 4. Then the extent tree of this file after punching is like ... 49507:[0]37:158047 49547:[0]58:158087 ... 5. Detailed procedure of punching hole [49544, 49546] 5.1. The block address space: ``` lblk ~49505 49506 49507~49543 49544~49546 49547~ ---------+------+-------------+----------------+-------- extent | hole | extent | hole | extent ---------+------+-------------+----------------+-------- pblk ~158045 158046 158047~158083 158084~158086 158087~ ``` 5.2. The detailed layout of cluster 39521: ``` cluster 39521 <-------------------------------> hole extent <----------------------><-------- lblk 49544 49545 49546 49547 +-------+-------+-------+-------+ | | | | | +-------+-------+-------+-------+ pblk 158084 1580845 158086 158087 ``` 5.3. The ftrace output when punching hole [49544, 49546]: - ext4_ext_remove_space (start 49544, end 49546) - ext4_ext_rm_leaf (start 49544, end 49546, last_extent [49507(158047), 40], partial [pclu 39522 lblk 0 state 2]) - ext4_remove_blocks (extent [49507(158047), 40], from 49544 to 49546, partial [pclu 39522 lblk 0 state 2] - ext4_free_blocks: (block 158084 count 4) - ext4_mballoc_free (extent 1/6753/1) 5.4. Ext4 error message in dmesg: EXT4-fs error (device vdb): mb_free_blocks:1457: group 1, block 158084:freeing already freed block (bit 6753); block bitmap corrupt. EXT4-fs error (device vdb): ext4_mb_generate_buddy:747: group 1, block bitmap and bg descriptor inconsistent: 19550 vs 19551 free clusters In this case, the whole cluster 39521 is freed mistakenly when freeing pblock 158084~158086 (i.e., the first three blocks of this cluster), although pblock 158087 (the last remaining block of this cluster) has not been freed yet. The root cause of this isuue is that, the pclu of the partial cluster is calculated mistakenly in ext4_ext_remove_space(). The correct partial_cluster.pclu (i.e., the cluster number of the first block in the next extent, that is, lblock 49597 (pblock 158086)) should be 39521 rather than 39522. Fixes: f4226d9e ("ext4: fix partial cluster initialization") Signed-off-by:
Jeffle Xu <jefflexu@linux.alibaba.com> Reviewed-by:
Eric Whitney <enwlinux@gmail.com> Cc: stable@kernel.org # v3.19+ Link: https://lore.kernel.org/r/1590121124-37096-1-git-send-email-jefflexu@linux.alibaba.comSigned-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Tom Rix authored
commit 65de5096 upstream. Clang's static analysis tool reports these double free memory errors. security/selinux/ss/services.c:2987:4: warning: Attempt to free released memory [unix.Malloc] kfree(bnames[i]); ^~~~~~~~~~~~~~~~ security/selinux/ss/services.c:2990:2: warning: Attempt to free released memory [unix.Malloc] kfree(bvalues); ^~~~~~~~~~~~~~ So improve the security_get_bools error handling by freeing these variables and setting their return pointers to NULL and the return len to 0 Cc: stable@vger.kernel.org Signed-off-by:
Tom Rix <trix@redhat.com> Acked-by:
Stephen Smalley <stephen.smalley.work@gmail.com> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Huacai Chen authored
commit 80e5f89d upstream. The command ring and cursor ring use different notify port addresses definition: QXL_IO_NOTIFY_CMD and QXL_IO_NOTIFY_CURSOR. However, in qxl_device_init() we use QXL_IO_NOTIFY_CMD to create both command ring and cursor ring. This doesn't cause any problems now, because QEMU's behaviors on QXL_IO_NOTIFY_CMD and QXL_IO_NOTIFY_CURSOR are the same. However, QEMU's behavior may be change in future, so let's fix it. P.S.: In the X.org QXL driver, the notify port address of cursor ring is correct. Signed-off-by:
Huacai Chen <chenhc@lemote.com> Cc: <stable@vger.kernel.org> Link: http://patchwork.freedesktop.org/patch/msgid/1585635488-17507-1-git-send-email-chenhc@lemote.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Lyude Paul authored
commit a5cb5fa6 upstream. Just add a bit more line wrapping, get rid of some extraneous whitespace, remove an unneeded goto label, and move around some variable declarations. No functional changes here. Signed-off-by:
-
Wolfram Sang authored
[ Upstream commit f78d4032 ] module_put() balances try_module_get(), not request_module(). Fix the error path to match that. Fixes: 2066facc ("drm/kms: slave encoder interface.") Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
-
Kai-Heng Feng authored
[ Upstream commit b5292111 ] Commit 130f4caf ("libata: Ensure ata_port probe has completed before detach") may cause system freeze during suspend. Using async_synchronize_full() in PM callbacks is wrong, since async callbacks that are already scheduled may wait for not-yet-scheduled callbacks, causes a circular dependency. Instead of using big hammer like async_synchronize_full(), use async cookie to make sure port probe are synced, without affecting other scheduled PM callbacks. Fixes: 130f4caf ("libata: Ensure ata_port probe has completed before detach") Suggested-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by:
-
