- 27 Jul, 2017 40 commits
-
-
Xiao Ni authored
commit b5d27718 upstream. The raid5 md device is created by the disks which we don't use the total size. For example, the size of the device is 5G and it just uses 3G of the devices to create one raid5 device. Then change the chunksize and wait reshape to finish. After reshape finishing stop the raid and assemble it again. It fails. mdadm -CR /dev/md0 -l5 -n3 /dev/loop[0-2] --size=3G --chunk=32 --assume-clean mdadm /dev/md0 --grow --chunk=64 wait reshape to finish mdadm -S /dev/md0 mdadm -As The error messages: [197519.814302] md: loop1 does not have a valid v1.2 superblock, not importing! [197519.821686] md: md_import_device returned -22 After reshape the data offset is changed. It selects backwards direction in this condition. In function super_1_load it compares the available space of the underlying device with sb->data_size. The new data offset gets bigger after reshape. So super_1_load returns -EINVAL. rdev->sectors is updated in md_finish_reshape. Then sb->data_size is set in super_1_sync based on rdev->sectors. So add md_finish_reshape in end_reshape. Signed-off-by:
Xiao Ni <xni@redhat.com> Acked-by:
Guoqing Jiang <gqjiang@suse.com> Signed-off-by:
Shaohua Li <shli@fb.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Heinz Mauelshagen authored
commit 4d49f1b4 upstream. Return 0 rather than BUG() if __rdev_sectors() fails and catch invalid rdev size in the constructor. Reported-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Jan Kara authored
commit a992f2d3 upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by creating __ext2_set_acl() function that does not call posix_acl_update_mode() and use it when inheriting ACLs. That prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 07393101 CC: linux-ext4@vger.kernel.org Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Toshi Kani authored
commit 4e3f0701 upstream. __add_badblock_range() does not account sector alignment when it sets 'num_sectors'. Therefore, an ARS error record range spanning across two sectors is set to a single sector length, which leaves the 2nd sector unprotected. Change __add_badblock_range() to set 'num_sectors' properly. Fixes: 0caeef63 ("libnvdimm: Add a poison list and export badblocks") Signed-off-by:
Toshi Kani <toshi.kani@hpe.com> Reviewed-by:
Vishal Verma <vishal.l.verma@intel.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Vishal Verma authored
commit 7e5a21df upstream. A leftover from the 'bandaid' fix that disabled BTT error clearing in rw_bytes resulted in an incorrect check. After we converted these checks over to use the NVDIMM_IO_ATOMIC flag, the ndns->claim check was both redundant, and incorrect. Remove it. Fixes: 3ae3d67b ("libnvdimm: add an atomic vs process context flag to rw_bytes") Cc: Dave Jiang <dave.jiang@intel.com> Cc: Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Vishal Verma authored
commit c13c43d5 upstream. btt_rw_page was not propagating errors frm btt_do_bvec, resulting in any IO errors via the rw_page path going unnoticed. the pmem driver recently fixed this in e10624f8 pmem: fail io-requests to known bad blocks but same problem in BTT went neglected. Fixes: 5212e11f ("nd_btt: atomic sector updates") Cc: Toshi Kani <toshi.kani@hpe.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Jeff Moyer <jmoyer@redhat.com> Signed-off-by:
-
Yasunori Goto authored
commit a117699c upstream. The root cause of panic is the num_pm of nfit_test1 is wrong. Though 1 is specified for num_pm at nfit_test_init(), it must be 2, because nfit_test1->spa_set[] array has 2 elements. Since the array is smaller than expected, the driver breaks other area. (it is often the link list of devres). As a result, panic occurs like the following example. CPU: 4 PID: 2233 Comm: lt-libndctl Tainted: G O 4.12.0-rc1+ #12 RIP: 0010:__list_del_entry_valid+0x6c/0xa0 Call Trace: release_nodes+0x76/0x260 devres_release_all+0x3c/0x50 device_release_driver_internal+0x159/0x200 device_release_driver+0x12/0x20 bus_remove_device+0xfd/0x170 device_del+0x1e8/0x330 platform_device_del+0x28/0x90 platform_device_unregister+0x12/0x30 nfit_test_exit+0x2a/0x93b [nfit_test] Signed-off-by:
Yasunori Goto <y-goto@jp.fujitsu.com> Signed-off-by:
-
David Härdeman authored
commit b2aceb73 upstream. The call to input_register_device() needs to take place before the repeat parameters are set or the input subsystem repeat handling will be disabled (as was already noted in the comments in that function). Signed-off-by:
David Härdeman <david@hardeman.nu> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Devin Heitmueller authored
commit 4e0973a9 upstream. Setting initial standard at the top of cx8800_initdev would cause the first call to cx88_set_tvnorm() to return without programming any registers (leaving the driver saying it's set to NTSC but the hardware isn't programmed). Even worse, any subsequent attempt to explicitly set it to NTSC-M will return success but actually fail to program the underlying registers unless first changing the standard to something other than NTSC-M. Set the initial standard later in the process, and make sure the field is zero at the beginning to ensure that the call always goes through. This regression was introduced in the following commit: commit ccd6f1d4 ("[media] cx88: move width, height and field to core struct") Author: Hans Verkuil <hans.verkuil@cisco.com> [media] cx88: move width, height and field to core struct Signed-off-by:
Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Marek Marczykowski-Górecki authored
commit c54590ca upstream. Userspace application can do a hypercall through /dev/xen/privcmd, and some for some hypercalls argument is a pointers to user-provided structure. When SMAP is supported and enabled, hypervisor can't access. So, lets allow it. The same applies to HYPERVISOR_dm_op, where additionally privcmd driver carefully verify buffer addresses. Signed-off-by:
Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
-
NeilBrown authored
commit cc27b0c7 upstream. If mddev_suspend() races with md_write_start() we can deadlock with mddev_suspend() waiting for the request that is currently in md_write_start() to complete the ->make_request() call, and md_write_start() waiting for the metadata to be updated to mark the array as 'dirty'. As metadata updates done by md_check_recovery() only happen then the mddev_lock() can be claimed, and as mddev_suspend() is often called with the lock held, these threads wait indefinitely for each other. We fix this by having md_write_start() abort if mddev_suspend() is happening, and ->make_request() aborts if md_write_start() aborted. md_make_request() can detect this abort, decrease the ->active_io count, and wait for mddev_suspend(). Reported-by:
Nix <nix@esperi.org.uk> Fix: 68866e42(MD: no sync IO while suspended) Signed-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
-
Mikulas Patocka authored
commit f9c79bc0 upstream. The function flush_signals clears all pending signals for the process. It may be used by kernel threads when we need to prepare a kernel thread for responding to signals. However using this function for an userspaces processes is incorrect - clearing signals without the program expecting it can cause misbehavior. The raid1 and raid5 code uses flush_signals in its request routine because it wants to prepare for an interruptible wait. This patch drops flush_signals and uses sigprocmask instead to block all signals (including SIGKILL) around the schedule() call. The signals are not lost, but the schedule() call won't respond to them. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Acked-by:
-
Dmitry Torokhov authored
commit 4cf56a89 upstream. Now that input core insists on having dev->absinfo when device claims to generate EV_ABS in its dev->evbit, we should not be blindly setting that bit. The code in question might have been needed before input_set_abs_params() started setting EV_ABS in device's evbit, but not anymore, and is now breaking devices such as SMART SPNL-6075 Touchscreen. Fixes: 6ecfe51b ("Input: refuse to register absolute devices ...") Reported-by:
Matthias Fend <Matthias.Fend@wolfvision.net> Tested-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Yoshihiro Shimoda authored
commit b8b9c974 upstream. A gadget driver will not disable eps immediately when ->disconnect() is called. But, since this driver assumes all eps stop after the ->disconnect(), unexpected behavior happens (especially in system suspend). So, this patch disables all eps in usbhsg_try_stop(). After disabling eps by renesas_usbhs driver, since some functions will be called by both a gadget and renesas_usbhs driver, renesas_usbhs driver should protect uep->pipe. To protect uep->pipe easily, this patch adds a new lock in struct usbhsg_uep. Fixes: 2f98382d ("usb: renesas_usbhs: Add Renesas USBHS Gadget") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Yoshihiro Shimoda authored
commit 59a0879a upstream. This patch fixes an issue that some registers may be not initialized after resume if the USBHSF_RUNTIME_PWCTRL is not set. Otherwise, if a cable is not connected, the driver will not enable INTENB0.VBSE after resume. And then, the driver cannot detect the VBUS. Fixes: ca8a282a ("usb: gadget: renesas_usbhs: add suspend/resume support") Signed-off-by:
-
Johan Hovold authored
commit fe855789 upstream. Add device-id entry for DATECS FP-2000 fiscal printer needing the NO_UNION_NORMAL quirk. Reported-by:
Anton Avramov <lukav@lukav.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Acked-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
-
Colin Ian King authored
commit 446230f5 upstream. When us->extra is null the driver is not initialized, however, a later call to osd200_scsi_to_ata is made that dereferences us->extra, causing a null pointer dereference. The code currently detects and reports that the driver is not initialized; add a return to avoid the subsequent dereference issue in this check. Thanks to Alan Stern for pointing out that srb->result needs setting to DID_ERROR << 16 Detected by CoverityScan, CID#100308 ("Dereference after null check") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Devin Heitmueller authored
commit d90b336f upstream. The recent changes in 4.9 to mandate USB buffers be heap allocated broke this driver, which was allocating the buffers on the stack. This resulted in the device failing at initialization. Introduce dedicated send/receive buffers as part of the state structure, and add a mutex to protect access to them. Note: we also had to tweak the API to mxl111sf_ctrl_msg to pass the pointer to the state struct rather than the device, since we need it inside the function to access the buffers and the mutex. This patch adjusts the callers to match the API change. Signed-off-by:
Doug Lung <dlung0@gmail.com> Cc: Michael Ira Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Jiahau Chang authored
commit 9da5a109 upstream. When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad performance was manifesting in Web browser use (like download large file such as ISO image). It is known limitation of ASM1042A that is not compatible with driver scheduling, As a workaround we can modify flow control handling of ASM1042A. The register we modify is changes the behavior [use quirk bit 28, usleep_range 40-60us, empty non-pci function -Mathias] Signed-off-by:
Jiahau Chang <Lars_chang@asmedia.com.tw> Signed-off-by:
Ian Pilcher <arequipeno@gmail.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Mathias Nyman authored
commit 4b895868 upstream. This off by one in stream_id indexing caused NULL pointer dereference and soft lockup on machines with USB attached SCSI devices connected to a hotpluggable xhci controller. The code that cleans up pending URBs for dead hosts tried to dereference a stream ring at the invalid stream_id 0. ep->stream_info->stream_rings[0] doesn't point to a ring. Start looping stream_id from 1 like in all the other places in the driver, and check that the ring exists before trying to kill URBs on it. Reported-by:
rocko r <rockorequin@gmail.com> Signed-off-by:
-
Mathias Nyman authored
commit a54408d0 upstream. A uncleared PLC (port link change) bit will prevent furuther port event interrupts for that port. Leaving it uncleared caused get_port_status() to timeout after 20000ms while waiting to get the final port event interrupt for resume -> U0 state change. This is a targeted fix for a specific case where we get a port resume event racing with xhci resume. The port event interrupt handler notices xHC is not yet running and bails out early, leaving PLC uncleared. The whole xhci port resuming needs more attention, but while working on it it anyways makes sense to always ensure PLC is cleared in get_port_status before setting a new link state and waiting for its completion. Signed-off-by:
-
Shu Wang authored
commit d6f5f071 upstream. Found this issue by kmemleak. xhci_run() did not check return val and free command for xhci_queue_vendor_command() unreferenced object 0xffff88011c0be500 (size 64): comm "kworker/0:1", pid 58, jiffies 4294670908 (age 50.420s) hex dump (first 32 bytes): backtrace: [<ffffffff8176166a>] kmemleak_alloc+0x4a/0xa0 [<ffffffff8121801a>] kmem_cache_alloc_trace+0xca/0x1d0 [<ffffffff81576bf4>] xhci_alloc_command+0x44/0x130 [<ffffffff8156f1cc>] xhci_run+0x4cc/0x630 [<ffffffff8153b84b>] usb_add_hcd+0x3bb/0x950 [<ffffffff8154eac8>] usb_hcd_pci_probe+0x188/0x500 [<ffffffff815851ac>] xhci_pci_probe+0x2c/0x220 [<ffffffff813d2ca5>] local_pci_probe+0x45/0xa0 [<ffffffff810a54e4>] work_for_cpu_fn+0x14/0x20 [<ffffffff810a8409>] process_one_work+0x149/0x360 [<ffffffff810a8d08>] worker_thread+0x1d8/0x3c0 [<ffffffff810ae7d9>] kthread+0x109/0x140 [<ffffffff8176d585>] ret_from_fork+0x25/0x30 [<ffffffffffffffff>] 0xffffffffffffffff Signed-off-by:
Shu Wang <shuwang@redhat.com> Signed-off-by:
-
Peter Chen authored
commit 576d5546 upstream. Both xhci_hub_control and xhci_disable_slot tries to hold spinlock, the spinlock recursion occurs when enters USB2 test mode. Fix it by unlock spinlock before calling xhci_disable_slot. Fixes: 0f1d832e ("usb: xhci: Add port test modes support for usb2") Signed-off-by:
Peter Chen <peter.chen@nxp.com> Signed-off-by:
-
Michael Hernandez authored
commit 6f9a22bc upstream. min_vecs is the minimum amount of vectors needed to operate in MSI-X mode which may just include the vectors that don't need affinity. Disabling affinity settings causes the qla2xxx driver scsi_add_host() to fail when blk_mq is enabled as the blk_mq_pci_map_queues() expects affinity masks on each vector. Fixes: dfef358b ("PCI/MSI: Don't apply affinity if there aren't enough vectors left") Signed-off-by:
Michael Hernandez <michael.hernandez@cavium.com> Signed-off-by:
Himanshu Madhani <himanshu.madhani@cavium.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Chen Yu authored
commit e60514bd upstream. Currently we saw a lot of "No irq handler" errors during hibernation, which caused the system hang finally: ata4.00: qc timeout (cmd 0xec) ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata4.00: revalidation failed (errno=-5) ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) do_IRQ: 31.151 No irq handler for vector According to above logs, there is an interrupt triggered and it is dispatched to CPU31 with a vector number 151, but there is no handler for it, thus this IRQ will not get acked and will cause an IRQ flood which kills the system. To be more specific, the 31.151 is an interrupt from the AHCI host controller. After some investigation, the reason why this issue is triggered is because the thaw_noirq() function does not restore the MSI/MSI-X settings across hibernation. The scenario is illustrated below: 1. Before hibernation, IRQ 34 is the handler for the AHCI device, which is bound to CPU31. 2. Hibernation starts, the AHCI device is put into low power state. 3. All the nonboot CPUs are put offline, so IRQ 34 has to be migrated to the last alive one - CPU0. 4. After the snapshot has been created, all the nonboot CPUs are brought up again; IRQ 34 remains bound to CPU0. 5. AHCI devices are put into D0. 6. The snapshot is written to the disk. The issue is triggered in step 6. The AHCI interrupt should be delivered to CPU0, however it is delivered to the original CPU31 instead, which causes the "No irq handler" issue. Ying Huang has provided a clue that, in step 3 it is possible that writing to the register might not take effect as the PCI devices have been suspended. In step 3, the IRQ 34 affinity should be modified from CPU31 to CPU0, but in fact it is not. In __pci_write_msi_msg(), if the device is already in low power state, the low level MSI message entry will not be updated but cached. During the device restore process after a normal suspend/resume, pci_restore_msi_state() writes the cached MSI back to the hardware. But this is not the case for hibernation. pci_restore_msi_state() is not currently called in pci_pm_thaw_noirq(), although pci_save_state() has saved the necessary PCI cached information in pci_pm_freeze_noirq(). Restore the PCI status for the device during hibernation. Otherwise the status might be lost across hibernation (for example, settings for MSI, MSI-X, ATS, ACS, IOV, etc.), which might cause problems during hibernation. Suggested-by:
Ying Huang <ying.huang@intel.com> Suggested-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Chen Yu <yu.c.chen@intel.com> [bhelgaas: changelog] Signed-off-by:
-
Shawn Lin authored
commit dc8cca5e upstream. Rockchip's RC has two banks of registers for the root port: a normal bank that is strictly compatible with the PCIe spec, and a privileged bank that can be used to change RO bits of root port registers. When probing the RC driver, we use the privileged bank to do some basic setup work as some RO bits are hw-inited to wrong value. But we didn't change to the normal bank after probing the driver. This leads to a serious problem when the PME code tries to clear the PME status by writing PCI_EXP_RTSTA_PME to the register of PCI_EXP_RTSTA. Per PCIe 3.0 spec, section 7.8.14, the PME status bit is RW1C. So the PME code is doing the right thing to clear the PME status but we find the RC doesn't clear it but actually setting it to one. So finally the system trap in pcie_pme_work_fn() as PCI_EXP_RTSTA_PME is true now forever. This issue can be reproduced by booting kernel with pci=nomsi. Use the normal register bank for the PCI config accessors. The privileged bank is used only internally by this driver. Fixes: e77f847d ("PCI: rockchip: Add Rockchip PCIe controller support") Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
-
Bjorn Helgaas authored
commit 13cfc732 upstream. Neither soft poweroff (transition to ACPI power state S5) nor suspend-to-RAM (transition to state S3) works on the Macbook Pro 11,4 and 11,5. The problem is related to the [mem 0x7fa00000-0x7fbfffff] space. When we use that space, e.g., by assigning it to the 00:1c.0 Root Port, the ACPI Power Management 1 Control Register (PM1_CNT) at [io 0x1804] doesn't work anymore. Linux does a soft poweroff (transition to S5) by writing to PM1_CNT. The theory about why this doesn't work is: - The write to PM1_CNT causes an SMI - The BIOS SMI handler depends on something in [mem 0x7fa00000-0x7fbfffff] - When Linux assigns [mem 0x7fa00000-0x7fbfffff] to the 00:1c.0 Port, it covers up whatever the SMI handler uses, so the SMI handler no longer works correctly Reserve the [mem 0x7fa00000-0x7fbfffff] space so we don't assign it to anything. This is voodoo programming, since we don't know what the real conflict is, but we've failed to find the root cause. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211 Tested-by: thejoe@gmail.com Signed-off-by:
-
Jon Derrick authored
commit 0cb259c4 upstream. Recent __call_srcu() changes have exposed that we need to cleanup SRCU structures after pci_stop_root_bus() calls into vmd_msi_free(). Fixes: 3906b918 ("PCI: vmd: Use SRCU as a local RCU to prevent delaying global RCU") Signed-off-by:
Jon Derrick <jonathan.derrick@intel.com> Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
-
Juergen Gross authored
commit c185ddec upstream. Commit dc6416f1 ("xen/x86: Call cpu_startup_entry(CPUHP_AP_ONLINE_IDLE) from xen_play_dead()") introduced an error leading to a stack overflow of the idle task when a cpu was brought offline/online many times: by calling cpu_startup_entry() instead of returning at the end of xen_play_dead() do_idle() would be entered again and again. Don't use cpu_startup_entry(), but cpuhp_online_idle() instead allowing to return from xen_play_dead(). Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
-
Madhavan Srinivasan authored
commit 20dd4c62 upstream. In case of continous sampling (non-marked), the code currently sets MMCRA[SDAR_MODE] to 0b01 (Update on TLB miss) for Power9 DD1. On DD2 and later it copies the sdar_mode value from the event code, which for most events is 0b00 (No updates). However we must set a non-zero value for SDAR_MODE when doing continuous sampling, so honor the event code, unless it's zero, in which case we use use 0b01 (Update on TLB miss). Fixes: 78b4416a ("powerpc/perf: Handle sdar_mode for marked event in power9") Signed-off-by:
Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit c6bb0b8d upstream. On radix, the process table entry we want to clear when destroying a context is entry 0, not entry 1. This has no *immediate* consequence on Power9, but it can cause other bugs to become worse. Fixes: 7e381c0f ("powerpc/mm/radix: Add mmu context handling callback for radix") Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
-
Oliver O'Halloran authored
commit 2400fd82 upstream. The workaround for the CELL timebase bug does not correctly mark cr0 as being clobbered. This means GCC doesn't know that the asm block changes cr0 and might leave the result of an unrelated comparison in cr0 across the block, which we then trash, leading to basically random behaviour. Fixes: 859deea9 ("[POWERPC] Cell timebase bug workaround") Signed-off-by:
Oliver O'Halloran <oohall@gmail.com> [mpe: Tweak change log and flag for stable] Signed-off-by:
-
Anton Blanchard authored
commit 64e756c5 upstream. From POWER4 onwards, mfocrf() only places the specified CR field into the destination GPR, and the rest of it is set to 0. The PowerPC AS from version 3.0 now requires this behaviour. The emulation code currently puts the entire CR into the destination GPR. Fix it. Fixes: 6888199f ("[POWERPC] Emulate more instructions in software") Signed-off-by:
Anton Blanchard <anton@samba.org> Acked-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by:
-
Anton Blanchard authored
commit 87c4b83e upstream. The mcrf emulation code was using the CR field number directly as the shift value, without taking into account that CR fields are numbered from 0-7 starting at the high bits. That meant it was looking at the CR fields in the reverse order. Fixes: cf87c3f6 ("powerpc: Emulate icbi, mcrf and conditional-trap instructions") Signed-off-by:
-
Michael Ellerman authored
commit 01e6a61a upstream. Although it's not documented anywhere, there is an expectation that atomic64_inc_not_zero() returns a result which fits in an int. This is the behaviour implemented on all arches except powerpc. This has caused at least one bug in practice, in the percpu-refcount code, where the long result from our atomic64_inc_not_zero() was truncated to an int leading to lost references and stuck systems. That was worked around in that code in commit 966d2b04 ("percpu-refcount: fix reference leak during percpu-atomic transition"). To the best of my grepping abilities there are no other callers in-tree which truncate the value, but we should fix it anyway. Because the breakage is subtle and potentially very harmful I'm also tagging it for stable. Code generation is largely unaffected because in most cases the callers are just using the result for a test anyway. In particular the case of fget() that was mentioned in commit a6cf7ed5 ("powerpc/atomic: Implement atomic*_inc_not_zero") generates exactly the same code. Fixes: a6cf7ed5 ("powerpc/atomic: Implement atomic*_inc_not_zero") Noticed-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Balbir Singh authored
commit 7f6d498e upstream. Commit 9abcc981 ("powerpc/mm/radix: Only add X for pages overlapping kernel text") changed the linear mapping on Radix to only mark the kernel text executable. However if the kernel is run relocated, for example as a kdump kernel, then the exception vectors are split from the kernel text, ie. they remain at real address 0. We tend to get away with it, because the kernel itself will usually be below 1G, which means the 1G page at 0-1G is marked executable and everything works OK. However if the kernel is loaded above 1G, or the system has less than 1G in total (meaning we can't use a 1G page), then the exception vectors will not be marked executable and the kernel will fail to boot. Fix it by also checking if the address range overlaps the exception vectors when deciding if we should add PAGE_KERNEL_X. Fixes: 9abcc981 ("powerpc/mm/radix: Only add X for pages overlapping kernel text") Signed-off-by:
Balbir Singh <bsingharora@gmail.com> [mpe: Combine with the existing check, rewrite change log] Signed-off-by:
-
Balbir Singh authored
commit e71ff982 upstream. Once upon a time there were only two PP (page protection) bits. In ISA 2.03 an additional PP bit was added, but because of the layout of the HPTE it could not be made contiguous with the existing PP bits. The result is that we now have three PP bits, named pp0, pp1, pp2, where pp0 occupies bit 63 of dword 1 of the HPTE and pp1 and pp2 occupy bits 1 and 0 respectively. Until recently Linux hasn't used pp0, however with the addition of _PAGE_KERNEL_RO we started using it. The problem arises in the LPAR code, where we need to translate the PP bits into the argument for the H_PROTECT hypercall. Currently the code only passes bits 0-2 of newpp, which covers pp1, pp2 and N (no execute), meaning pp0 is not passed to the hypervisor at all. We can't simply pass it through in bit 63, as that would collide with a different field in the flags argument, as defined in PAPR. Instead we have to shift it down to bit 8 (IBM bit 55). Fixes: e58e87ad ("powerpc/mm: Update _PAGE_KERNEL_RO") Signed-off-by:
-
Michael Ellerman authored
commit 9abcc981 upstream. Currently we map the whole linear mapping with PAGE_KERNEL_X. Instead we should check if the page overlaps the kernel text and only then add PAGE_KERNEL_X. Note that we still use 1G pages if they're available, so this will typically still result in a 1G executable page at KERNELBASE. So this fix is primarily useful for catching stray branches to high linear mapping addresses. Without this patch, we can execute at 1G in xmon using: 0:mon> m c000000040000000 c000000040000000 00 l c000000040000000 00000000 01006038 c000000040000004 00000000 2000804e c000000040000008 00000000 x 0:mon> di c000000040000000 c000000040000000 38600001 li r3,1 c000000040000004 4e800020 blr 0:mon> p c000000040000000 return value is 0x1 After we get a 400 as expected: 0:mon> p c000000040000000 *** 400 exception occurred Fixes: 2bfd65e4 ("powerpc/mm/radix: Add radix callbacks for early init routines") Signed-off-by:
-
Paolo Bonzini authored
commit a680f1d4 upstream. Multi-queue virtio-scsi uses a different scsi_host_template struct. Add the .device_alloc field there, too. Fixes: 25d1d50e Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Reviewed-by:
Fam Zheng <famz@redhat.com> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Bart Van Assche authored
commit 9f4ab18a upstream. scsiback_release_cmd() must not dereference se_cmd->se_tmr_req because that memory is freed by target_free_cmd_mem() before scsiback_release_cmd() is called. Fix this use-after-free by inlining struct scsiback_tmr into struct vscsibk_pend. Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Reviewed-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
