- 05 Dec, 2017 40 commits
-
-
Ken Wang authored
commit ab6613b7 upstream. Fixes vbios fetching on certain headless boards. Signed-off-by:
Ken Wang <Ken.Wang@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
ozeng authored
commit c5066129 upstream. v1: Properly allocate TLB invalidation engine to avoid conflict. v2: Added comments to codes Signed-off-by:
Oak Zeng <Oak.Zeng@amd.com> Reviewed-by:
Christian Konig <christian.koenig@amd.com> Signed-off-by:
-
Christian König authored
commit a695e437 upstream. The bo structure is freed up in case of an error, so we can't do any accounting if that happens. Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Ken Wang authored
commit 76d6172b upstream. Old value from bringup was wrong. Signed-off-by:
-
Dan Carpenter authored
commit 78aa02c7 upstream. After commit ea09729c ("drm/amdgpu: rework page directory filling v2") then it becomes a lot harder to verify that "r" is initialized. My static checker complains and so I've reviewed the code. It does look like it might be buggy... Anyway, it doesn't hurt to set "r" to zero at the start. Reviewed-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Dan Carpenter authored
commit 40a9960b upstream. We shifted some code around in commit 9cca0b8e ("drm/amdgpu: move amdgpu_cs_sysvm_access_required into find_mapping") and now my static checker complains that "r" might not be initialized at the end of the function. I've reviewed the code, and that seems possible, but it's also possible I may have missed something. Reviewed-by:
-
Alex Deucher authored
commit 18c437ca upstream. Fixes distorted colors on some cards on resume from suspend. This reverts commit b9729b17. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98832 Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99163 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=107001Reviewed-by:
-
Jeff Lien authored
commit 8c97eecc upstream. And increase the existing delay to cover this device as well. Signed-off-by:
Jeff Lien <jeff.lien@wdc.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Peter Rosin authored
commit 68615eb0 upstream. With a nxp,se97 chip on an atmel sama5d31 board, the I2C adapter driver is not always capable of avoiding the 25-35 ms timeout as specified by the SMBUS protocol. This may cause silent corruption of the last bit of any transfer, e.g. a one is read instead of a zero if the sensor chip times out. This also affects the eeprom half of the nxp-se97 chip, where this silent corruption was originally noticed. Other I2C adapters probably suffer similar issues, e.g. bit-banging comes to mind as risky... The SMBUS register in the nxp chip is not a standard Jedec register, but it is not special to the nxp chips either, at least the atmel chips have the same mechanism. Therefore, do not special case this on the manufacturer, it is opt-in via the device property anyway. Signed-off-by:
Peter Rosin <peda@axentia.se> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Rui Hua authored
commit e393aa24 upstream. When we send a read request and hit the clean data in cache device, there is a situation called cache read race in bcache(see the commit in the tail of cache_look_up(), the following explaination just copy from there): The bucket we're reading from might be reused while our bio is in flight, and we could then end up reading the wrong data. We guard against this by checking (in bch_cache_read_endio()) if the pointer is stale again; if so, we treat it as an error (s->iop.error = -EINTR) and reread from the backing device (but we don't pass that error up anywhere) It should be noted that cache read race happened under normal circumstances, not the circumstance when SSD failed, it was counted and shown in /sys/fs/bcache/XXX/internal/cache_read_races. Without this patch, when we use writeback mode, we will never reread from the backing device when cache read race happened, until the whole cache device is clean, because the condition (s->recoverable && (dc && !atomic_read(&dc->has_dirty))) is false in cached_dev_read_error(). In this situation, the s->iop.error(= -EINTR) will be passed up, at last, user will receive -EINTR when it's bio end, this is not suitable, and wield to up-application. In this patch, we use s->read_dirty_data to judge whether the read request hit dirty data in cache device, it is safe to reread data from the backing device when the read request hit clean data. This can not only handle cache read race, but also recover data when failed read request from cache device. [edited by mlyle to fix up whitespace, commit log title, comment spelling] Fixes: d59b2379 ("bcache: only permit to recovery read error when cache device is clean") Signed-off-by:
Hua Rui <huarui.dev@gmail.com> Reviewed-by:
Michael Lyle <mlyle@lyle.org> Reviewed-by:
Coly Li <colyli@suse.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Coly Li authored
commit d59b2379 upstream. When bcache does read I/Os, for example in writeback or writethrough mode, if a read request on cache device is failed, bcache will try to recovery the request by reading from cached device. If the data on cached device is not synced with cache device, then requester will get a stale data. For critical storage system like database, providing stale data from recovery may result an application level data corruption, which is unacceptible. With this patch, for a failed read request in writeback or writethrough mode, recovery a recoverable read request only happens when cache device is clean. That is to say, all data on cached device is up to update. For other cache modes in bcache, read request will never hit cached_dev_read_error(), they don't need this patch. Please note, because cache mode can be switched arbitrarily in run time, a writethrough mode might be switched from a writeback mode. Therefore checking dc->has_data in writethrough mode still makes sense. Changelog: V4: Fix parens error pointed by Michael Lyle. v3: By response from Kent Oversteet, he thinks recovering stale data is a bug to fix, and option to permit it is unnecessary. So this version the sysfs file is removed. v2: rename sysfs entry from allow_stale_data_on_failure to allow_stale_data_on_failure, and fix the confusing commit log. v1: initial patch posted. [small change to patch comment spelling by mlyle] Signed-off-by:
Arne Wolf <awolf@lenovo.com> Reviewed-by:
-
Huacai Chen authored
commit cf33c1ee upstream. This patch try to fix the building error on MIPS. The reason is MIPS has already defined the PTR macro, which conflicts with the PTR macro in include/uapi/linux/bcache.h. [fixed by mlyle: corrected a line-length issue] Signed-off-by:
Huacai Chen <chenhc@lemote.com> Reviewed-by:
-
Vaibhav Jain authored
commit 12841f87 upstream. During an eeh a kernel-oops is reported if no vPHB is allocated to the AFU. This happens as during AFU init, an error in creation of vPHB is a non-fatal error. Hence afu->phb should always be checked for NULL before iterating over it for the virtual AFU pci devices. This patch fixes the kenel-oops by adding a NULL pointer check for afu->phb before it is dereferenced. Fixes: 9e8df8a2 ("cxl: EEH support") Signed-off-by:
Vaibhav Jain <vaibhav@linux.vnet.ibm.com> Acked-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Acked-by:
Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Hans de Goede authored
commit 6e0c9507 upstream. On Apollo Lake devices the BIOS does not set up IRQ routing for the i801 SMBUS controller IRQ, so we end up with dev->irq set to IRQ_NOTCONNECTED. Detect this and do not try to use the irq in this case silencing: i801_smbus 0000:00:1f.1: Failed to allocate irq -2147483648: -107 BugLink: https://communities.intel.com/thread/114759Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Heiner Kallweit authored
commit d9bcd462 upstream. So far we completely rely on the caller to provide valid arguments. To be on the safe side perform an own sanity check. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by:
-
Bartosz Golaszewski authored
commit 5478e478 upstream. There's an ilog2() expansion in AT24_DEVICE_MAGIC() which rounds down the actual size of EUI-48 byte array in at24mac402 eeproms to 4 from 6, making it impossible to read it all. Fix it by manually adjusting the value in probe(). This patch contains a temporary fix that is suitable for stable branches. Eventually we'll probably remove the call to ilog2() while converting the magic values to actual structs. Fixes: 0b813658 ("eeprom: at24: add support for at24mac series") Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
commit 644a1f19 upstream. Chip datasheet mentions that word addresses other than the actual start position of the MAC delivers undefined results. So fix this. Current implementation doesn't work due to this wrong offset. Fixes: 0b813658 ("eeprom: at24: add support for at24mac series") Signed-off-by:
-
Lv Zheng authored
commit a64a62ce upstream. On platforms (ASUS X550ZE and possibly all ASUS X series) with valid ECDT EC but invalid DSDT EC, EC PM ops won't be invoked as ECDT EC is not an ACPI device. Thus the following commit actually removed post-resume acpi_ec_enable_event() invocation for such platforms, and triggered a regression on them that after being resumed, EC (actually should be ECDT) driver stops handling EC events: Commit: c2b46d67 Subject: ACPI / EC: Add PM operations to improve event handling for resume process Notice that the root cause actually is "ECDT is not an ACPI device" rather than "the timing of acpi_ec_enable_event() invocation", this patch fixes this issue by enumerating ECDT EC as an ACPI device. Due to the existence of the noirq stage, the ability of tuning the timing of acpi_ec_enable_event() invocation is still meaningful. This patch is a little bit different from the posted fix by moving acpi_config_boot_ec() from acpi_ec_ecdt_start() to acpi_ec_add() to make sure that EC event handling won't be stopped as long as the ACPI EC driver is bound. Thus the following sequence shouldn't disable EC event handling: unbind,suspend,resume,bind. Fixes: c2b46d67 (ACPI / EC: Add PM operations to improve event handling for resume process) Link: https://bugzilla.kernel.org/show_bug.cgi?id=196847Reported-by:
Luya Tshimbalanga <luya@fedoraproject.org> Tested-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Bastian Stender authored
commit c892b0d8 upstream. The sysfs entry "ocr" was missing the 0x prefix to identify it as hex formatted. Fixes: 5fb06af7 ("mmc: core: Extend sysfs with OCR register") Signed-off-by:
Bastian Stender <bst@pengutronix.de> [Ulf: Amended change to also cover SD-cards] Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Bastian Stender authored
commit 80a780a1 upstream. The sysfs entry "pre_eol_info" was missing the 0x prefix to identify it as hex formatted. Fixes: 46bc5c40 ("mmc: core: Export device lifetime information through sysfs") Signed-off-by:
-
Adrian Hunter authored
commit f9f0da98 upstream. The card is not necessarily being removed, but the debugfs files must be removed when the driver is removed, otherwise they will continue to exist after unbinding the card from the driver. e.g. # echo "mmc1:0001" > /sys/bus/mmc/drivers/mmcblk/unbind # cat /sys/kernel/debug/mmc1/mmc1\:0001/ext_csd [ 173.634584] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 [ 173.643356] IP: mmc_ext_csd_open+0x5e/0x170 A complication is that the debugfs_root may have already been removed, so check for that too. Fixes: 627c3ccf ("mmc: debugfs: Move block debugfs into block module") Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Adrian Hunter authored
commit ebe7dd45 upstream. The block driver must be resumed if the mmc bus fails to suspend the card. Signed-off-by:
-
Adrian Hunter authored
commit fb8e456e upstream. blk_get_request() can fail, always check the return value. Fixes: 0493f6fe ("mmc: block: Move boot partition locking into a driver op") Fixes: 3ecd8cf2 ("mmc: block: move multi-ioctl() to use block layer") Fixes: 614f0388 ("mmc: block: move single ioctl() commands to block requests") Fixes: 627c3ccf ("mmc: debugfs: Move block debugfs into block module") Signed-off-by:
-
Adrian Hunter authored
commit 34c089e8 upstream. Ensure blk_get_request() is paired with blk_put_request(). Fixes: 0493f6fe ("mmc: block: Move boot partition locking into a driver op") Fixes: 627c3ccf ("mmc: debugfs: Move block debugfs into block module") Signed-off-by:
-
Ulf Hansson authored
commit 250dcd11 upstream. The commit de3ee99b ("mmc: Delete bounce buffer handling") deletes the bounce buffer handling, but also causes the max_req_size for sdhci to be increased, in case when max_segs == 1. This causes errors for sdhci-pci Ricoh variant, about the swiotlb buffer to become full. Fix the issue, by taking IO_TLB_SEGSIZE and IO_TLB_SHIFT into account when deciding the max_req_size for sdhci. Reported-by:
Jiri Slaby <jslaby@suse.cz> Fixes: de3ee99b ("mmc: Delete bounce buffer handling") Signed-off-by:
-
Dr. David Alan Gilbert authored
commit 12806ba9 upstream. In x2apic mode the LDR is fixed based on the ID rather than separately loadable like it was before x2. When kvm_apic_set_state is called, the base is set, and if it has the X2APIC_ENABLE flag set then the LDR is calculated; however that value gets overwritten by the memcpy a few lines below overwriting it with the value that came from userland. The symptom is a lack of EOI after loading the state (e.g. after a QEMU migration) and is due to the EOI bitmap being wrong due to the incorrect LDR. This was seen with a Win2016 guest under Qemu with irqchip=split whose USB mouse didn't work after a VM migration. This corresponds to RH bug: https://bugzilla.redhat.com/show_bug.cgi?id=1502591Reported-by:
Yiqian Wei <yiwei@redhat.com> Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> [Applied fixup from Liran Alon. - Paolo] Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Dr. David Alan Gilbert authored
commit e872fa94 upstream. Split out the ldr calculation from kvm_apic_set_x2apic_id since we're about to reuse it in the following patch. Signed-off-by:
-
Paolo Bonzini authored
commit 6ea6e843 upstream. Sometimes, a processor might execute an instruction while another processor is updating the page tables for that instruction's code page, but before the TLB shootdown completes. The interesting case happens if the page is in the TLB. In general, the processor will succeed in executing the instruction and nothing bad happens. However, what if the instruction is an MMIO access? If *that* happens, KVM invokes the emulator, and the emulator gets the updated page tables. If the update side had marked the code page as non present, the page table walk then will fail and so will x86_decode_insn. Unfortunately, even though kvm_fetch_guest_virt is correctly returning X86EMUL_PROPAGATE_FAULT, x86_decode_insn's caller treats the failure as a fatal error if the instruction cannot simply be reexecuted (as is the case for MMIO). And this in fact happened sometimes when rebooting Windows 2012r2 guests. Just checking ctxt->have_exception and injecting the exception if true is enough to fix the case. Thanks to Eduardo Habkost for helping in the debugging of this issue. Reported-by:
Yanan Fu <yfu@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
Liran Alon authored
commit 61cb57c9 upstream. Instruction emulation after trapping a #UD exception can result in an MMIO access, for example when emulating a MOVBE on a processor that doesn't support the instruction. In this case, the #UD vmexit handler must exit to user mode, but there wasn't any code to do so. Add it for both VMX and SVM. Signed-off-by:
Liran Alon <liran.alon@oracle.com> Reviewed-by:
Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
Wanpeng Li <wanpeng.li@hotmail.com> Reviewed-by:
-
Liran Alon authored
commit 51c4b8bb upstream. When guest passes KVM it's pvclock-page GPA via WRMSR to MSR_KVM_SYSTEM_TIME / MSR_KVM_SYSTEM_TIME_NEW, KVM don't initialize pvclock-page to some start-values. It just requests a clock-update which will happen before entering to guest. The clock-update logic will call kvm_setup_pvclock_page() to update the pvclock-page with info. However, kvm_setup_pvclock_page() *wrongly* assumes that the version-field is initialized to an even number. This is wrong because at first-time write, field could be any-value. Fix simply makes sure that if first-time version-field is odd, increment it once more to make it even and only then start standard logic. This follows same logic as done in other pvclock shared-pages (See kvm_write_wall_clock() and record_steal_time()). Signed-off-by:
-
Michael Ellerman authored
commit 2621e945 upstream. The code that cleans up the IAMR/AMOR before kexec'ing failed to remember that when we're running as a guest AMOR is not writable, it's hypervisor privileged. They symptom is that the kexec stops before entering purgatory and nothing else is seen on the console. If you examine the state of the system all threads will be in the 0x700 program check handler. Fix it by making the write to AMOR dependent on HV mode. Fixes: 1e2a516e ("powerpc/kexec: Fix radix to hash kexec due to IAMR/AMOR") Reported-by:
Yilin Zhang <yilzhang@redhat.com> Debugged-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
Balbir Singh <bsingharora@gmail.com> Reviewed-by:
-
Mahesh Salgaonkar authored
commit a3961f82 upstream. Rebooting into a new kernel with kexec fails in trace_tlbie() which is called from native_hpte_clear(). This happens if the running kernel has CONFIG_LOCKDEP enabled. With lockdep enabled, the tracepoints always execute few RCU checks regardless of whether tracing is on or off. We are already in the last phase of kexec sequence in real mode with HILE_BE set. At this point the RCU check ends up in RCU_LOCKDEP_WARN and causes kexec to fail. Fix this by not calling trace_tlbie() from native_hpte_clear(). mpe: It's not safe to call trace points at this point in the kexec path, even if we could avoid the RCU checks/warnings. The only solution is to not call them. Fixes: 0428491c ("powerpc/mm: Trace tlbie(l) instructions") Signed-off-by:
Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Reported-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Suggested-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by:
-
Ard Biesheuvel authored
commit be0f272b upstream. When building the arm64 kernel with both CONFIG_ARM64_MODULE_PLTS and CONFIG_DYNAMIC_FTRACE enabled, the ftrace-mod.o object file is built with the kernel and contains a trampoline that is linked into each module, so that modules can be loaded far away from the kernel and still reach the ftrace entry point in the core kernel with an ordinary relative branch, as is emitted by the compiler instrumentation code dynamic ftrace relies on. In order to be able to build out of tree modules, this object file needs to be included into the linux-headers or linux-devel packages, which is undesirable, as it makes arm64 a special case (although a precedent does exist for 32-bit PPC). Given that the trampoline essentially consists of a PLT entry, let's not bother with a source or object file for it, and simply patch it in whenever the trampoline is being populated, using the existing PLT support routines. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Ard Biesheuvel authored
commit 7e8b9c1d upstream. To allow the ftrace trampoline code to reuse the PLT entry routines, factor it out and move it into asm/module.h. Signed-off-by:
-
John Johansen authored
commit b12cbb21 upstream. The apparmor_audit_data struct ordering got messed up during a merge conflict, resulting in the signal integer and peer pointer being in a union instead of a struct. For most of the 4.13 and 4.14 life cycle, this was hidden by commit 651e28c5 ("apparmor: add base infastructure for socket mediation") which fixed the apparmor_audit_data struct when its data was added. When that commit was reverted in -rc7 the signal audit bug was exposed, and unfortunately it never showed up in any of the testing until after 4.14 was released. Shaun Khan, Zephaniah E. Loss-Cutler-Hull filed nearly simultaneous bug reports (with different oopes, the smaller of which is included below). Full credit goes to Tetsuo Handa for jumping on this as well and noticing the audit data struct problem and reporting it. [ 76.178568] BUG: unable to handle kernel paging request at ffffffff0eee3bc0 [ 76.178579] IP: audit_signal_cb+0x6c/0xe0 [ 76.178581] PGD 1a640a067 P4D 1a640a067 PUD 0 [ 76.178586] Oops: 0000 [#1] PREEMPT SMP [ 76.178589] Modules linked in: fuse rfcomm bnep usblp uvcvideo btusb btrtl btbcm btintel bluetooth ecdh_generic ip6table_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter ip_tables x_tables intel_rapl joydev wmi_bmof serio_raw iwldvm iwlwifi shpchp kvm_intel kvm irqbypass autofs4 algif_skcipher nls_iso8859_1 nls_cp437 crc32_pclmul ghash_clmulni_intel [ 76.178620] CPU: 0 PID: 10675 Comm: pidgin Not tainted 4.14.0-f1-dirty #135 [ 76.178623] Hardware name: Hewlett-Packard HP EliteBook Folio 9470m/18DF, BIOS 68IBD Ver. F.62 10/22/2015 [ 76.178625] task: ffff9c7a94c31dc0 task.stack: ffffa09b02a4c000 [ 76.178628] RIP: 0010:audit_signal_cb+0x6c/0xe0 [ 76.178631] RSP: 0018:ffffa09b02a4fc08 EFLAGS: 00010292 [ 76.178634] RAX: ffffa09b02a4fd60 RBX: ffff9c7aee0741f8 RCX: 0000000000000000 [ 76.178636] RDX: ffffffffee012290 RSI: 0000000000000006 RDI: ffff9c7a9493d800 [ 76.178638] RBP: ffffa09b02a4fd40 R08: 000000000000004d R09: ffffa09b02a4fc46 [ 76.178641] R10: ffffa09b02a4fcb8 R11: ffff9c7ab44f5072 R12: ffffa09b02a4fd40 [ 76.178643] R13: ffffffff9e447be0 R14: ffff9c7a94c31dc0 R15: 0000000000000001 [ 76.178646] FS: 00007f8b11ba2a80(0000) GS:ffff9c7afea00000(0000) knlGS:0000000000000000 [ 76.178648] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 76.178650] CR2: ffffffff0eee3bc0 CR3: 00000003d5209002 CR4: 00000000001606f0 [ 76.178652] Call Trace: [ 76.178660] common_lsm_audit+0x1da/0x780 [ 76.178665] ? d_absolute_path+0x60/0x90 [ 76.178669] ? aa_check_perms+0xcd/0xe0 [ 76.178672] aa_check_perms+0xcd/0xe0 [ 76.178675] profile_signal_perm.part.0+0x90/0xa0 [ 76.178679] aa_may_signal+0x16e/0x1b0 [ 76.178686] apparmor_task_kill+0x51/0x120 [ 76.178690] security_task_kill+0x44/0x60 [ 76.178695] group_send_sig_info+0x25/0x60 [ 76.178699] kill_pid_info+0x36/0x60 [ 76.178703] SYSC_kill+0xdb/0x180 [ 76.178707] ? preempt_count_sub+0x92/0xd0 [ 76.178712] ? _raw_write_unlock_irq+0x13/0x30 [ 76.178716] ? task_work_run+0x6a/0x90 [ 76.178720] ? exit_to_usermode_loop+0x80/0xa0 [ 76.178723] entry_SYSCALL_64_fastpath+0x13/0x94 [ 76.178727] RIP: 0033:0x7f8b0e58b767 [ 76.178729] RSP: 002b:00007fff19efd4d8 EFLAGS: 00000206 ORIG_RAX: 000000000000003e [ 76.178732] RAX: ffffffffffffffda RBX: 0000557f3e3c2050 RCX: 00007f8b0e58b767 [ 76.178735] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000000263b [ 76.178737] RBP: 0000000000000000 R08: 0000557f3e3c2270 R09: 0000000000000001 [ 76.178739] R10: 000000000000022d R11: 0000000000000206 R12: 0000000000000000 [ 76.178741] R13: 0000000000000001 R14: 0000557f3e3c13c0 R15: 0000000000000000 [ 76.178745] Code: 48 8b 55 18 48 89 df 41 b8 20 00 08 01 5b 5d 48 8b 42 10 48 8b 52 30 48 63 48 4c 48 8b 44 c8 48 31 c9 48 8b 70 38 e9 f4 fd 00 00 <48> 8b 14 d5 40 27 e5 9e 48 c7 c6 7d 07 19 9f 48 89 df e8 fd 35 [ 76.178794] RIP: audit_signal_cb+0x6c/0xe0 RSP: ffffa09b02a4fc08 [ 76.178796] CR2: ffffffff0eee3bc0 [ 76.178799] ---[ end trace 514af9529297f1a3 ]--- Fixes: cd1dbf76 ("apparmor: add the ability to mediate signals") Reported-by:
Zephaniah E. Loss-Cutler-Hull <warp-spam_kernel@aehallh.com> Reported-by:
Shuah Khan <shuahkh@osg.samsung.com> Suggested-by:
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Tested-by:
Ivan Kozik <ivan@ludios.org> Tested-by:
Christian Boltz <apparmor@cboltz.de> Tested-by:
John Johansen <john.johansen@canonical.com> Signed-off-by:
-
Peter Ujfalusi authored
commit 23970e15 upstream. I believe the intention of the commit 2c9fc9bf ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver") was to identify omap4430 ES1.x, omap4430 ES2.x and other OMAP4 revisions, like omap4460. By using family=OMAP4 in the match the code will treat omap4460 ES1.x in a same way as it would treat omap4430 ES1.x This breaks HDMI audio on OMAP4460 devices (PandaES for example). Correct the match rule so we are not going to get false positive match. Fixes: 2c9fc9bf ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver") Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Laurent Pinchart authored
commit bf25dac3 upstream. Commit d178e034 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code") replaced usage of platform data version with SoC matching to configure DPI VDDS. The SoC match entries were incorrect, they should have matched on the machine name instead of the SoC family. Fix it. The result was observed on OpenPandora with OMAP3530 where the panel only had the Blue channel and Red&Green were missing. It was not observed on GTA04 with DM3730. Fixes: d178e034 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code") Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com> Tested-by:
-
Martin Schwidefsky authored
commit 345f8f34 upstream. This reverts commit a73dc537. Reducing the base address for 31-bit PIE executables from (STACK_TOP/3)*2 to 4MB broke several compat programs which use -fpie to move the executable out of the lower 16MB. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Vasily Averin authored
commit 3a2b19d1 upstream. Commit efda760f ("lockd: fix lockd shutdown race") is incorrect, it removes lockd_manager and disarm grace_period_end for init_net only. If nfsd was started from another net namespace lockd_up_net() calls set_grace_period() that adds lockd_manager into per-netns list and queues grace_period_end delayed work. These action should be reverted in lockd_down_net(). Otherwise it can lead to double list_add on after restart nfsd in netns, and to use-after-free if non-disarmed delayed work will be executed after netns destroy. Fixes: efda760f ("lockd: fix lockd shutdown race") Signed-off-by:
Vasily Averin <vvs@virtuozzo.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Ondrej Mosnáček authored
commit c14ca838 upstream. The skcipher_walk_aead_common function calls scatterwalk_copychunks on the input and output walks to skip the associated data. If the AD end at an SG list entry boundary, then after these calls the walks will still be pointing to the end of the skipped region. These offsets are later checked for alignment in skcipher_walk_next, so the skcipher_walk may detect the alignment incorrectly. This patch fixes it by calling scatterwalk_done after the copychunks calls to ensure that the offsets refer to the right SG list entry. Fixes: b286d8b1 ("crypto: skcipher - Add skcipher walk interface") Signed-off-by:
Ondrej Mosnacek <omosnacek@gmail.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
