- 29 Sep, 2015 3 commits
-
-
Ming Lei authored
commit 596f5aad upstream. There may be lots of pending requests so that the buffer of PAGE_SIZE can't hold them at all. One typical example is scsi-mq, the queue depth(.can_queue) of scsi_host and blk-mq is quite big but scsi_device's queue_depth is a bit small(.cmd_per_lun), then it is quite easy to have lots of pending requests in hw queue. This patch fixes the following warning and the related memory destruction. [ 359.025101] fill_read_buffer: blk_mq_hw_sysfs_show+0x0/0x7d returned bad count^M [ 359.055595] irq event stamp: 15537^M [ 359.055606] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC ^M [ 359.055614] Dumping ftrace buffer:^M [ 359.055660] (ftrace buffer empty)^M [ 359.055672] Modules linked in: nbd ipv6 kvm_intel kvm serio_raw^M [ 359.055678] CPU: 4 PID: 21631 Comm: stress-ng-sysfs Not tainted 4.2.0-rc5-next-20150805 #434^M [ 359.055679] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011^M [ 359.055682] task: ffff8802161cc000 ti: ffff88021b4a8000 task.ti: ffff88021b4a8000^M [ 359.055693] RIP: 0010:[<ffffffff811541c5>] [<ffffffff811541c5>] __kmalloc+0xe8/0x152^M Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Christophe Ricard authored
commit 5a9e0ffc upstream. skb can be NULL and may lead to a NULL pointer error. Add a check condition before setting HCI rx buffer. Signed-off-by:
Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Christophe Ricard authored
commit 5a357006 upstream. st21nfca_hci_load_session() calls kfree_skb() on unitialized variables skb_pipe_info and skb_pipe_list if the call to nfc_hci_connect_gate() failed. Reword the error path to not use these variables when they are not initialized. While at it, there seemed to be a memory leak because skb_pipe_info was only freed once, after the for-loop, even though several ones were created by nfc_hci_send_cmd. Fixes: ec03ff1a ("NFC: st21nfca: Remove skb_pipe_list and skb_pipe_info useless allocation") Acked-by:
Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by:
-
- 21 Sep, 2015 37 commits
-
-
Greg Kroah-Hartman authored
-
Caesar Wang authored
commit cb8cc37f upstream. The following was seen in branch[0] build. arch/arm/mach-rockchip/platsmp.c:154:23: error: 'rockchip_secondary_startup' undeclared (first use in this function) branch[0]: git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git v4.3-armsoc/soc The broken build is caused by the commit fe4407c0 ("ARM: rockchip: fix the CPU soft reset"). Signed-off-by:
Caesar Wang <wxt@rock-chips.com> The breakage was a result of it being wrongly merged in my branch with the cache invalidation rework from Russell 02b4e275 ("ARM: v7 setup function should invalidate L1 cache"). Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Kees Cook authored
commit a068acf2 upstream. Many file systems that implement the show_options hook fail to correctly escape their output which could lead to unescaped characters (e.g. new lines) leaking into /proc/mounts and /proc/[pid]/mountinfo files. This could lead to confusion, spoofed entries (resulting in things like systemd issuing false d-bus "mount" notifications), and who knows what else. This looks like it would only be the root user stepping on themselves, but it's possible weird things could happen in containers or in other situations with delegated mount privileges. Here's an example using overlay with setuid fusermount trusting the contents of /proc/mounts (via the /etc/mtab symlink). Imagine the use of "sudo" is something more sneaky: $ BASE="ovl" $ MNT="$BASE/mnt" $ LOW="$BASE/lower" $ UP="$BASE/upper" $ WORK="$BASE/work/ 0 0 none /proc fuse.pwn user_id=1000" $ mkdir -p "$LOW" "$UP" "$WORK" $ sudo mount -t overlay -o "lowerdir=$LOW,upperdir=$UP,workdir=$WORK" none /mnt $ cat /proc/mounts none /root/ovl/mnt overlay rw,relatime,lowerdir=ovl/lower,upperdir=ovl/upper,workdir=ovl/work/ 0 0 none /proc fuse.pwn user_id=1000 0 0 $ fusermount -u /proc $ cat /proc/mounts cat: /proc/mounts: No such file or directory This fixes the problem by adding new seq_show_option and seq_show_option_n helpers, and updating the vulnerable show_option handlers to use them as needed. Some, like SELinux, need to be open coded due to unusual existing escape mechanisms. [akpm@linux-foundation.org: add lost chunk, per Kees] [keescook@chromium.org: seq_show_option should be using const parameters] Signed-off-by:
Kees Cook <keescook@chromium.org> Acked-by:
Serge Hallyn <serge.hallyn@canonical.com> Acked-by:
Jan Kara <jack@suse.com> Acked-by:
Paul Moore <paul@paul-moore.com> Cc: J. R. Okajima <hooanon05g@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Mikulas Patocka authored
commit f49a26e7 upstream. Update ctime and mtime when a directory is modified. (though OS/2 doesn't update them anyway) Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
-
Eric W. Biederman authored
commit 4b75de86 upstream. Before the make_empty_dir_inode calls were introduce into proc, sysfs, and sysctl those directories when stated reported an i_size of 0. make_empty_dir_inode started reporting an i_size of 2. At least one userspace application depended on stat returning i_size of 0. So modify make_empty_dir_inode to cause an i_size of 0 to be reported for these directories. Reported-by:
Tejun Heo <tj@kernel.org> Acked-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Grant Likely authored
commit 7f5dcaf1 upstream. The unregister path of platform_device is broken. On registration, it will register all resources with either a parent already set, or type==IORESOURCE_{IO,MEM}. However, on unregister it will release everything with type==IORESOURCE_{IO,MEM}, but ignore the others. There are also cases where resources don't get registered in the first place, like with devices created by of_platform_populate()*. Fix the unregister path to be symmetrical with the register path by checking the parent pointer instead of the type field to decide which resources to unregister. This is safe because the upshot of the registration path algorithm is that registered resources have a parent pointer, and non-registered resources do not. * It can be argued that of_platform_populate() should be registering it's resources, and they argument has some merit. However, there are quite a few platforms that end up broken if we try to do that due to overlapping resources in the device tree. Until that is fixed, we need to solve the immediate problem. Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Rob Herring <robh@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by:
Grant Likely <grant.likely@linaro.org> Tested-by:
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Tested-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Jiang Liu authored
commit 5d0ddfeb upstream. Nick Meier reported a regression with HyperV that " After rebooting the VM, the following messages are logged in syslog when trying to load the tulip driver: tulip: Linux Tulip drivers version 1.1.15 (Feb 27, 2007) tulip: 0000:00:0a.0: PCI INT A: failed to register GSI tulip: Cannot enable tulip board #0, aborting tulip: probe of 0000:00:0a.0 failed with error -16 Errors occur in 3.19.0 kernel Works in 3.17 kernel. " According to the ACPI dump file posted by Nick at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072 The ACPI MADT table includes an interrupt source overridden entry for ACPI SCI: [236h 0566 1] Subtable Type : 02 <Interrupt Source Override> [237h 0567 1] Length : 0A [238h 0568 1] Bus : 00 [239h 0569 1] Source : 09 [23Ah 0570 4] Interrupt : 00000009 [23Eh 0574 2] Flags (decoded below) : 000D Polarity : 1 Trigger Mode : 3 And in DSDT table, we have _PRT method to define PCI interrupts, which eventually goes to: Name (PRSA, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {3,4,5,7,9,10,11,12,14,15} }) Name (PRSB, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {3,4,5,7,9,10,11,12,14,15} }) Name (PRSC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {3,4,5,7,9,10,11,12,14,15} }) Name (PRSD, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {3,4,5,7,9,10,11,12,14,15} }) According to the MADT and DSDT tables, IRQ 9 may be used for: 1) ACPI SCI in level, high mode 2) PCI legacy IRQ in level, low mode So there's a conflict in polarity setting for IRQ 9. Prior to commit cd68f6bd ("x86, irq, acpi: Get rid of special handling of GSI for ACPI SCI"), ACPI SCI is handled specially and there's no check for conflicts between ACPI SCI and PCI legagy IRQ. And it seems that the HyperV hypervisor doesn't make use of the polarity configuration in IOAPIC entry, so it just works. Commit cd68f6bd gets rid of the specially handling of ACPI SCI, and then the pin attribute checking code discloses the conflicts between ACPI SCI and PCI legacy IRQ on HyperV virtual machine, and rejects the request to assign IRQ9 to PCI devices. So penalize legacy IRQ used by ACPI SCI and mark it unusable if ACPI SCI attributes conflict with PCI IRQ attributes. Please refer to following links for more information: https://bugzilla.kernel.org/show_bug.cgi?id=101301 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072 Fixes: cd68f6bd ("x86, irq, acpi: Get rid of special handling of GSI for ACPI SCI") Reported-and-tested-by:
Nick Meier <nmeier@microsoft.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Heiko Stuebner authored
commit 1a1b698b upstream. The watchdog irq is actually SPI 79, which translates to the original 111 in the manual where the SPI irqs start at 32. The current dw_wdt driver does not use the irq at all, so this issue never surfaced. Nevertheless fix this for a time we want to use the irq. Fixes: 2ab557b7 ("ARM: dts: rockchip: add core rk3288 dtsi") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Caesar Wang authored
commit fe4407c0 upstream. We need different orderings when turning a core on and turning a core off. In one case we need to assert reset before turning power off. In ther other case we need to turn power on and the deassert reset. In general, the correct flow is: CPU off: reset_control_assert regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), BIT(pd)) wait_for_power_domain_to_turn_off CPU on: regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), 0) wait_for_power_domain_to_turn_on reset_control_deassert This is needed for stressing CPU up/down, as per: cd /sys/devices/system/cpu/ for i in $(seq 10000); do echo "================= $i ============" for j in $(seq 100); do while [[ "$(cat cpu1/online)$(cat cpu2/online)$(cat cpu3/online)" != "000"" ]] echo 0 > cpu1/online echo 0 > cpu2/online echo 0 > cpu3/online done while [[ "$(cat cpu1/online)$(cat cpu2/online)$(cat cpu3/online)" != "111" ]]; do echo 1 > cpu1/online echo 1 > cpu2/online echo 1 > cpu3/online done done done The following is reproducable log: [34466.186812] PM: noirq suspend of devices complete after 0.669 msecs [34466.186824] Disabling non-boot CPUs ... [34466.187509] CPU1: shutdown [34466.188672] CPU2: shutdown [34473.736627] Kernel panic - not syncing:Watchdog detected hard LOCKUP on cpu 0 ....... or others similar log: ....... [ 4072.454453] CPU1: shutdown [ 4072.504436] CPU2: shutdown [ 4072.554426] CPU3: shutdown [ 4072.577827] CPU1: Booted secondary processor [ 4072.582611] CPU2: Booted secondary processor <hang> Tested by cpu up/down scripts, the results told us need delay more time before write the sram. The wait time is affected by many aspects (e.g: cpu frequency, bootrom frequency, sram frequency, bus speed, ...). Although the cpus other than cpu0 will write the sram, the speedy is no the same as cpu0, if the cpu0 early wake up, perhaps the other cpus can't startup. As we know, the cpu0 can wake up when the cpu1/2/3 write the 'sram+4/8' and send the sev. Anyway..... At the moment, 1ms delay will be happy work for cpu up/down scripts test. Signed-off-by:
Kever Yang <kever.yang@rock-chips.com> Fixes: 3ee851e2 ("ARM: rockchip: add basic smp support for rk3288") Signed-off-by:
-
Vignesh R authored
commit b9e23f32 upstream. Legacy IPs like PWMSS, present under l4per2_7xx_clkdm, cannot support smart-idle when its clock domain is in HW_AUTO on DRA7 SoCs. Hence, program clock domain to SW_WKUP. Signed-off-by:
Vignesh R <vigneshr@ti.com> Acked-by:
Tero Kristo <t-kristo@ti.com> Reviewed-by:
Paul Walmsley <paul@pwsan.com> Signed-off-by:
-
Hyungwon Hwang authored
commit 65e32933 upstream. After the commit abc0b144 ("drm: Perform basic sanity checks on probed modes"), proper clock-frequency becomes mandatory for validating the mode of panel. The display does not work if there is no mode validated. Also, this clock-frequency must be set appropriately for getting required frame rate. Fixes: abc0b144 ("drm: Perform basic sanity checks on probed modes") Signed-off-by:
Hyungwon Hwang <human.hwang@samsung.com> Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Sigend-off-by:
Kukjin Kim <kgene@kernel.org> Signed-off-by:
-
Benjamin Cama authored
commit 5be9fc23 upstream. Since v3.18, attempts to deliver IRQ0 are rejected, breaking orion5x. Fix this by increasing all interrupts by one, as did 5d6bed2a for dove. Also, force MULTI_IRQ_HANDLER for all orion platforms (including dove) as the specific handler is needed to shift back IRQ numbers by one. [gregory.clement@free-electrons.com]: moved the select MULTI_IRQ_HANDLER from PLAT_ORION_LEGACY to ARCH_ORION5X as it broke the build for dove. Fixes: a71b092a ("ARM: Convert handle_IRQ to use __handle_domain_irq") Signed-off-by:
Benjamin Cama <benoar@dolka.fr> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Tested-by:
Detlef Vollmann <dv@vollmann.ch> Signed-off-by:
-
David Daney authored
commit 3a496b00 upstream. If the internal call to of_address_to_resource() fails, we end up looping forever in of_find_matching_node_by_address(). This can be caused by a defective device tree, or calling with an incorrect matches argument. Fix by calling of_find_matching_node() unconditionally at the end of the loop. Signed-off-by:
David Daney <david.daney@cavium.com> Signed-off-by:
-
Thierry Reding authored
commit 95169cd2 upstream. Make sure to only drop the reference to the OF node after it's been successfully obtained. Fixes: 3568df3d ("soc: tegra: Add thermal reset (thermtrip) support to PMC") Reviewed-by:
Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Xie XiuQi authored
commit 1b484655 upstream. Zhang Liguang reported the following issue: 1) System detects a CMCI storm on the current CPU. 2) Kernel disables the CMCI interrupt on banks owned by the current CPU and switches to poll mode 3) After the CMCI storm subsides, kernel switches back to interrupt mode 4) We expect the system to reenable the CMCI interrupt on banks owned by the current CPU mce_intel_adjust_timer |-> cmci_reenable |-> cmci_discover # owned banks are ignored here static void cmci_discover(int banks) ... for (i = 0; i < banks; i++) { ... if (test_bit(i, owned)) # ownd banks is ignore here continue; So convert cmci_storm_disable_banks() to cmci_toggle_interrupt_mode() which controls whether to enable or disable CMCI interrupts with its argument. NB: We cannot clear the owned bit because the banks won't be polled, otherwise. See: 27f6c573 ("x86, CMCI: Add proper detection of end of CMCI storms") for more info. Reported-by:
Zhang Liguang <zhangliguang@huawei.com> Signed-off-by:
Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: huawei.libin@huawei.com Cc: linux-edac <linux-edac@vger.kernel.org> Cc: rui.xiang@huawei.com Link: http://lkml.kernel.org/r/1439396985-12812-10-git-send-email-bp@alien8.deSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Kishon Vijay Abraham I authored
commit c329061b upstream. regulator_disable of pbias always writes '0' to the enable_reg. However actual disable value of pbias regulator is not always '0'. Fix it by populating the disable_val in pbias_reg_info for the various platforms and assign it to the disable_val of pbias regulator descriptor. This will be used by regulator_disable_regmap while disabling pbias regulator. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Sudip Mukherjee authored
commit bab383de upstream. parport_find_base() will implicitly do parport_get_port() which increases the refcount. Then parport_register_device() will again increment the refcount. But while unloading the module we are only doing parport_unregister_device() decrementing the refcount only once. We add an parport_put_port() to neutralize the effect of parport_get_port(). Signed-off-by:
Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by:
-
Ricardo Ribalda Delgado authored
commit 16ea9b8a upstream. Once the module process a transfer in irq mode, the next poll transfer will not work because the transmitter is left in inhibited state. Fixes: 22417352 (Use polling mode on small transfers) Reported-by:
Edward Kigwana <ekigwana@scires.com> Signed-off-by:
-
Ricardo Ribalda Delgado authored
commit 74346841 upstream. The ACK of an inexistent IRQ can trigger an spurious IRQ that breaks the txrx logic. This has been observed on axi_quad_spi:3.2 core. This patch only ACKs IRQs that have not been Acknowledge jet. Reported-by:
-
Peter Chen authored
commit 4bc58eb1 upstream. Fix the name of attribute Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Peter Chen authored
commit 8cd50626 upstream. Fix the name of attribute Signed-off-by:
-
Masahiro Yamada authored
commit 64526370 upstream. Currently, devres_get() passes devres_free() the pointer to devres, but devres_free() should be given with the pointer to resource data. Fixes: 9ac7849e ("devres: device resource management") Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
-
Max Filippov authored
commit 77d6273e upstream. call12 can't be safely used as the first call in the inline function, because the compiler does not extend the stack frame of the bounding function accordingly, which may result in corruption of local variables. If a call needs to be done, do call8 first followed by call12. For pure assembly code in _switch_to increase stack frame size of the bounding function. Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
-
Max Filippov authored
commit 4229fb12 upstream. Userspace return code may skip restoring THREADPTR register if there are no registers that need to be zeroed. This leads to spurious failures in libc NPTL tests. Always restore THREADPTR on return to userspace. Signed-off-by:
-
Haozhong Zhang authored
commit d7add054 upstream. When kvm_set_msr_common() handles a guest's write to MSR_IA32_TSC_ADJUST, it will calcuate an adjustment based on the data written by guest and then use it to adjust TSC offset by calling a call-back adjust_tsc_offset(). The 3rd parameter of adjust_tsc_offset() indicates whether the adjustment is in host TSC cycles or in guest TSC cycles. If SVM TSC scaling is enabled, adjust_tsc_offset() [i.e. svm_adjust_tsc_offset()] will first scale the adjustment; otherwise, it will just use the unscaled one. As the MSR write here comes from the guest, the adjustment is in guest TSC cycles. However, the current kvm_set_msr_common() uses it as a value in host TSC cycles (by using true as the 3rd parameter of adjust_tsc_offset()), which can result in an incorrect adjustment of TSC offset if SVM TSC scaling is enabled. This patch fixes this problem. Signed-off-by:
Haozhong Zhang <haozhong.zhang@intel.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Paul Mackerras authored
commit 1e5bf454 upstream. The reference (R) and change (C) bits in a HPT entry can be set by hardware at any time up until the HPTE is invalidated and the TLB invalidation sequence has completed. This means that when removing a HPTE, we need to read the HPTE after the invalidation sequence has completed in order to obtain reliable values of R and C. The code in kvmppc_do_h_remove() used to do this. However, commit 6f22bd32 ("KVM: PPC: Book3S HV: Make HTAB code LE host aware") removed the read after invalidation as a side effect of other changes. This restores the read of the HPTE after invalidation. The user-visible effect of this bug would be that when migrating a guest, there is a small probability that a page modified by the guest and then unmapped by the guest might not get re-transmitted and thus the destination might end up with a stale copy of the page. Fixes: 6f22bd32Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
Alexander Graf <agraf@suse.de> Signed-off-by:
-
Gautham R. Shenoy authored
commit 06554d9f upstream. The code that handles the case when we receive a H_DOORBELL interrupt has a comment which says "Hypervisor doorbell - exit only if host IPI flag set". However, the current code does not actually check if the host IPI flag is set. This is due to a comparison instruction that got missed. As a result, the current code performs the exit to host only if some sibling thread or a sibling sub-core is exiting to the host. This implies that, an IPI sent to a sibling core in (subcores-per-core != 1) mode will be missed by the host unless the sibling core is on the exit path to the host. This patch adds the missing comparison operation which will ensure that when HOST_IPI flag is set, we unconditionally exit to the host. Fixes: 66feed61Signed-off-by:
Gautham R. Shenoy <ego@linux.vnet.ibm.com> Reviewed-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
-
Xiao Guangrong authored
commit 6f691251 upstream. We got the bug that qemu complained with "KVM: unknown exit, hardware reason 31" and KVM shown these info: [84245.284948] EPT: Misconfiguration. [84245.285056] EPT: GPA: 0xfeda848 [84245.285154] ept_misconfig_inspect_spte: spte 0x5eaef50107 level 4 [84245.285344] ept_misconfig_inspect_spte: spte 0x5f5fadc107 level 3 [84245.285532] ept_misconfig_inspect_spte: spte 0x5141d18107 level 2 [84245.285723] ept_misconfig_inspect_spte: spte 0x52e40dad77 level 1 This is because we got a mmio #PF and the handler see the mmio spte becomes normal (points to the ram page) However, this is valid after introducing fast mmio spte invalidation which increases the generation-number instead of zapping mmio sptes, a example is as follows: 1. QEMU drops mmio region by adding a new memslot 2. invalidate all mmio sptes 3. VCPU 0 VCPU 1 access the invalid mmio spte access the region originally was MMIO before set the spte to the normal ram map mmio #PF check the spte and see it becomes normal ram mapping !!! This patch fixes the bug just by dropping the check in mmio handler, it's good for backport. Full check will be introduced in later patches Reported-by:
Pavel Shirshov <ru.pchel@gmail.com> Tested-by:
Xiao Guangrong <guangrong.xiao@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Ellen Wang authored
commit 6d00d153 upstream. When doing an I2C_SMBUS_BYTE write (one byte write, no address), the data to be written is in "command" not "data->byte". Signed-off-by:
Ellen Wang <ellen@cumulusnetworks.com> Acked-by:
Wolfram Sang <wsa@the-dreams.de> Reviewed-by:
Antonio Borneo <borneo.antonio@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.com> Signed-off-by:
-
Ellen Wang authored
commit 29e2d6d1 upstream. Change all occurrences of be16 to le16 in cp2112_xfer(), because SMBUS words are little endian, not big endian. Signed-off-by:
-
Don Zickus authored
commit 3af4e5a9 upstream. It was reported that after 10-20 reboots, a usb keyboard plugged into a docking station would not work unless it was replugged in. Using usbmon, it turns out the interrupt URBs were streaming with callback errors of -71 for some reason. The hid-core.c::hid_io_error was supposed to retry and then reset, but the reset wasn't really happening. The check for HID_NO_BANDWIDTH was inverted. Fix was simple. Tested by reporter and locally by me by unplugging a keyboard halfway until I could recreate a stream of errors but no disconnect. Signed-off-by:
Don Zickus <dzickus@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Andrey Ryabinin authored
commit 71c6da84 upstream. Currently context size (cra_ctxsize) doesn't specified for ghash_async_alg. Which means it's zero. Thus crypto_create_tfm() doesn't allocate needed space for ghash_async_ctx, so any read/write to ctx (e.g. in ghash_async_init_tfm()) is not valid. Signed-off-by:
Andrey Ryabinin <aryabinin@odin.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Leonidas Da Silva Barbosa authored
commit 3c5f0ed7 upstream. GHASH table algorithm is using a big endian key. In little endian machines key will be LE ordered. After a lxvd2x instruction key is loaded as it is, LE/BE order, in first case it'll generate a wrong table resulting in wrong hashes from the algorithm. Bug affects only LE machines. In order to fix it we do a swap for loaded key. Signed-off-by:
Leonidas S Barbosa <leosilva@linux.vnet.ibm.com> Signed-off-by:
-
Robert Baldyga authored
commit 736cd79f upstream. So far DMA mode were activated when only number of bytes to send was equal or greater than min_dma_size. Due to requirement that DMA transaction buffer should be aligned to cache line size, the excessive bytes were written to FIFO before starting DMA transaction. The problem occurred when FIFO size were smaller than cache alignment, because writing all excessive bytes to FIFO would fail. It happened in DMA mode when PIO interrupts disabled, which caused driver hung. The solution is to test if buffer is alligned to cache line size before activating DMA mode, and if it's not, running PIO mode to align buffer and then starting DMA transaction. In PIO mode, when interrupts are enabled, lack of space in FIFO isn't the problem, so buffer aligning will always finish with success. Reported-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
-
Marek Szyprowski authored
commit 81ccb2a6 upstream. Due to some of serial ports can have FIFO size smaller than cache line size, and because of need to align DMA buffer address to cache line size, it's necessary to calculate minimum number of bytes for which we want to start DMA transaction to be at least cache line size. The simplest way to meet this requirement is to get maximum of cache line size and FIFO size. Reported-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Adam Lee authored
commit 89c043a6 upstream. Pericom PI7C9X795[1248] are Uno/Dual/Quad/Octal UART devices, this patch enables them, also defines PCI_VENDOR_ID_PERICOM here. Signed-off-by:
Adam Lee <adam.lee@canonical.com> Signed-off-by:
-
Maciej S. Szmigiero authored
commit 1d700277 upstream. This way this device can be used with irtty-sir - at least on Toshiba Satellite A20-S103 it is not configured by default and needs PNP activation before it starts to respond on I/O ports. This device has actually its own driver (ali-ircc), but this driver seems to be non-functional for a very long time (see http://permalink.gmane.org/gmane.linux.irda.general/484 http://permalink.gmane.org/gmane.network.protocols.obex.openobex.user/943 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535070 ). Signed-off-by:
Maciej Szmigiero <mail@maciej.szmigiero.name> Signed-off-by:
-
