Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1352397 > unrolled thread

[PATCH 4.4 00/74] 4.4.5-stable review

Started byGreg Kroah-Hartman <gregkh@linuxfoundation.org>
First post2016-03-08 01:30 +0100
Last post2016-03-09 03:10 +0100
Articles 14 — 4 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 4.4 00/74] 4.4.5-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-03-08 01:30 +0100
    [PATCH 4.4 09/74] parisc: Fix ptrace syscall number and return value modification Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-03-08 01:30 +0100
    [PATCH 4.4 18/74] arm/arm64: KVM: Fix ioctl error handling Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-03-08 01:30 +0100
    [PATCH 4.4 10/74] mips/kvm: fix ioctl error handling Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-03-08 01:30 +0100
    [PATCH 4.4 12/74] fbcon: set a default value to blink interval Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-03-08 01:30 +0100
    [PATCH 4.4 03/74] Btrfs: fix deadlock running delayed iputs at transaction commit time Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-03-08 01:30 +0100
    [PATCH 4.4 07/74] block: Initialize max_dev_sectors to 0 Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-03-08 01:30 +0100
    [PATCH 4.4 16/74] vfio: fix ioctl error handling Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-03-08 01:30 +0100
    Re: [PATCH 4.4 00/74] 4.4.5-stable review Guenter Roeck <linux@roeck-us.net> - 2016-03-08 12:50 +0100
      Re: [PATCH 4.4 00/74] 4.4.5-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-03-08 15:20 +0100
    Re: [PATCH 4.4 00/74] 4.4.5-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-03-08 15:40 +0100
      Re: [PATCH 4.4 00/74] 4.4.5-stable review Kevin Hilman <khilman@baylibre.com> - 2016-03-09 06:40 +0100
    Re: [PATCH 4.4 00/74] 4.4.5-stable review Shuah Khan <shuahkh@osg.samsung.com> - 2016-03-08 17:30 +0100
      Re: [PATCH 4.4 00/74] 4.4.5-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-03-09 03:10 +0100

#1352397 — [PATCH 4.4 00/74] 4.4.5-stable review

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-03-08 01:30 +0100
Subject[PATCH 4.4 00/74] 4.4.5-stable review
Message-ID<radnP-1zk-3@gated-at.bofh.it>
This is the start of the stable review cycle for the 4.4.5 release.
There are 74 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Mar 10 00:02:56 UTC 2016.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.5-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 4.4.5-rc1

Alex Deucher <alexdeucher@gmail.com>
    drm/amdgpu: fix topaz/tonga gmc assignment in 4.4 stable

Rusty Russell <rusty@rustcorp.com.au>
    modules: fix longstanding /proc/kallsyms vs module insertion race.

Gerd Hoffmann <kraxel@redhat.com>
    drm/i915: refine qemu south bridge detection

Gerd Hoffmann <kraxel@redhat.com>
    drm/i915: more virtual south bridge detection

Ming Lei <ming.lei@canonical.com>
    block: get the 1st and last bvec via helpers

Ming Lei <ming.lei@canonical.com>
    block: check virt boundary in bio_will_gap()

Michel Dänzer <michel.daenzer@amd.com>
    drm/amdgpu: Use drm_calloc_large for VM page_tables array

Javi Merino <javi.merino@arm.com>
    thermal: cpu_cooling: fix out of bounds access in time_in_idle

Wolfram Sang <wsa@the-dreams.de>
    i2c: brcmstb: allocate correct amount of memory for regmap

Richard Weinberger <richard@nod.at>
    ubi: Fix out of bounds write in volume update code

Frederic Barrat <fbarrat@linux.vnet.ibm.com>
    cxl: Fix PSL timebase synchronization detection

Maciej W. Rozycki <macro@imgtec.com>
    MIPS: traps: Fix SIGFPE information leak from `do_ov' and `do_trap_or_bp'

Govindraj Raja <govindraj.raja@imgtec.com>
    MIPS: scache: Fix scache init with invalid line size.

Yegor Yefremov <yegorslists@googlemail.com>
    USB: serial: option: add support for Quectel UC20

Daniele Palmas <dnlplm@gmail.com>
    USB: serial: option: add support for Telit LE922 PID 0x1045

Bjørn Mork <bjorn@mork.no>
    USB: qcserial: add Sierra Wireless EM74xx device ID

Patrik Halfar <patrik_halfar@halfarit.cz>
    USB: qcserial: add Dell Wireless 5809e Gobi 4G HSPA+ (rev3)

Vittorio Alfieri <vittorio88@gmail.com>
    USB: cp210x: Add ID for Parrot NMEA GPS Flight Recorder

Peter Chen <peter.chen@nxp.com>
    usb: chipidea: otg: change workqueue ci_otg as freezable

Takashi Iwai <tiwai@suse.de>
    ALSA: timer: Fix broken compat timer user status ioctl

Takashi Iwai <tiwai@suse.de>
    ALSA: hdspm: Fix zero-division

Takashi Iwai <tiwai@suse.de>
    ALSA: hdsp: Fix wrong boolean ctl value accesses

Takashi Iwai <tiwai@suse.de>
    ALSA: hdspm: Fix wrong boolean ctl value accesses

Takashi Iwai <tiwai@suse.de>
    ALSA: seq: oss: Don't drain at closing a client

Takashi Iwai <tiwai@suse.de>
    ALSA: pcm: Fix ioctls for X32 ABI

Takashi Iwai <tiwai@suse.de>
    ALSA: timer: Fix ioctls for X32 ABI

Takashi Iwai <tiwai@suse.de>
    ALSA: rawmidi: Fix ioctls X32 ABI

Simon South <simon@simonsouth.com>
    ALSA: hda - Fix mic issues on Acer Aspire E1-472

Takashi Iwai <tiwai@suse.de>
    ALSA: ctl: Fix ioctls for X32 ABI

Dennis Kadioglu <denk@post.com>
    ALSA: usb-audio: Add a quirk for Plantronics DA45

Hans Verkuil <hansverk@cisco.com>
    adv7604: fix tx 5v detect regression

Robert Jarzmik <robert.jarzmik@free.fr>
    dmaengine: pxa_dma: fix cyclic transfers

David Woodhouse <David.Woodhouse@intel.com>
    Fix directory hardlinks from deleted directories

David Woodhouse <David.Woodhouse@intel.com>
    jffs2: Fix page lock / f->sem deadlock

Thomas Betker <thomas.betker@rohde-schwarz.com>
    Revert "jffs2: Fix lock acquisition order bug in jffs2_write_begin"

Filipe Manana <fdmanana@suse.com>
    Btrfs: fix loading of orphan roots leading to BUG_ON

Gabor Juhos <juhosg@openwrt.org>
    pata-rb532-cf: get rid of the irq_to_gpio() call

Steven Rostedt (Red Hat) <rostedt@goodmis.org>
    tracing: Do not have 'comm' filter override event 'comm' field

Manuel Lauss <manuel.lauss@gmail.com>
    ata: ahci: don't mark HotPlugCapable Ports as external/removable

Todd E Brandt <todd.e.brandt@linux.intel.com>
    PM / sleep / x86: Fix crash on graph trace through x86 suspend

Ard Biesheuvel <ard.biesheuvel@linaro.org>
    arm64: vmemmap: use virtual projection of linear region

Alexandra Yates <alexandra.yates@linux.intel.com>
    Adding Intel Lewisburg device IDs for SATA

Tejun Heo <tj@kernel.org>
    writeback: flush inode cgroup wb switches instead of pinning super_block

Ming Lei <ming.lei@canonical.com>
    block: bio: introduce helpers to get the 1st and last bvec

Harvey Hunt <harvey.hunt@imgtec.com>
    libata: Align ata_device's id on a cacheline

Arnd Bergmann <arnd@arndb.de>
    libata: fix HDIO_GET_32BIT ioctl

Arindam Nath <arindam.nath@amd.com>
    drm/amdgpu: return from atombios_dp_get_dpcd only when error

Chunming Zhou <David1.Zhou@amd.com>
    drm/amdgpu/gfx8: specify which engine to wait before vm flush

Christian König <christian.koenig@amd.com>
    drm/amdgpu: apply gfx_v8 fixes to gfx_v7 as well

Alex Deucher <alexander.deucher@amd.com>
    drm/amdgpu/pm: update current crtc info after setting the powerstate

Alex Deucher <alexander.deucher@amd.com>
    drm/radeon/pm: update current crtc info after setting the powerstate

Timothy Pearson <tpearson@raptorengineeringinc.com>
    drm/ast: Fix incorrect register check for DRAM width

Mike Christie <mchristi@redhat.com>
    target: Fix WRITE_SAME/DISCARD conversion to linux 512b sectors

Joerg Roedel <jroedel@suse.de>
    iommu/vt-d: Use BUS_NOTIFY_REMOVED_DEVICE in hotplug path

Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
    iommu/amd: Fix boot warning when device 00:00.0 is not iommu covered

Jay Cornwall <jay@jcornwall.me>
    iommu/amd: Apply workaround for ATS write permission check

Michael S. Tsirkin <mst@redhat.com>
    arm/arm64: KVM: Fix ioctl error handling

Paolo Bonzini <pbonzini@redhat.com>
    KVM: x86: fix root cause for missed hardware breakpoints

Michael S. Tsirkin <mst@redhat.com>
    vfio: fix ioctl error handling

Yadan Fan <ydfan@novell.com>
    Fix cifs_uniqueid_to_ino_t() function for s390x

Pavel Shilovsky <pshilovsky@samba.org>
    CIFS: Fix SMB2+ interim response processing for read requests

Justin Maggard <jmaggard10@gmail.com>
    cifs: fix out-of-bounds access in lease parsing

Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
    fbcon: set a default value to blink interval

Owen Hofmann <osh@google.com>
    kvm: x86: Update tsc multiplier on change.

Michael S. Tsirkin <mst@redhat.com>
    mips/kvm: fix ioctl error handling

Helge Deller <deller@gmx.de>
    parisc: Fix ptrace syscall number and return value modification

Murali Karicheri <m-karicheri2@ti.com>
    PCI: keystone: Fix MSI code that retrieves struct pcie_port pointer

Keith Busch <keith.busch@intel.com>
    block: Initialize max_dev_sectors to 0

Oded Gabbay <oded.gabbay@gmail.com>
    drm/amdgpu: mask out WC from BO on unsupported arches

Qu Wenruo <quwenruo@cn.fujitsu.com>
    btrfs: async-thread: Fix a use-after-free error for trace

Zhao Lei <zhaolei@cn.fujitsu.com>
    btrfs: Fix no_space in write and rm loop

Filipe Manana <fdmanana@suse.com>
    Btrfs: fix deadlock running delayed iputs at transaction commit time

Geert Uytterhoeven <geert+renesas@glider.be>
    drivers: sh: Restore legacy clock domain on SuperH platforms

Al Viro <viro@zeniv.linux.org.uk>
    use ->d_seq to get coherency between ->d_inode and ->d_flags


-------------

Diffstat:

 Makefile                                       |   4 +-
 arch/arm/kvm/guest.c                           |   2 +-
 arch/arm64/include/asm/pgtable.h               |   7 +-
 arch/arm64/kvm/guest.c                         |   2 +-
 arch/arm64/mm/init.c                           |   4 +-
 arch/mips/kernel/traps.c                       |  13 +-
 arch/mips/kvm/mips.c                           |   4 +-
 arch/mips/mm/sc-mips.c                         |  13 +-
 arch/parisc/kernel/ptrace.c                    |  16 ++-
 arch/parisc/kernel/syscall.S                   |   5 +-
 arch/x86/kernel/acpi/sleep.c                   |   7 +
 arch/x86/kvm/vmx.c                             |  14 +-
 arch/x86/kvm/x86.c                             |   9 +-
 block/blk-settings.c                           |   4 +-
 drivers/ata/ahci.c                             |   6 +
 drivers/ata/libahci.c                          |   3 +-
 drivers/ata/libata-scsi.c                      |  11 +-
 drivers/ata/pata_rb532_cf.c                    |  11 +-
 drivers/dma/pxa_dma.c                          |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c     |   8 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c         |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c         |   7 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c          |  13 ++
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c          |   3 +-
 drivers/gpu/drm/amd/amdgpu/vi.c                |  12 +-
 drivers/gpu/drm/ast/ast_main.c                 |   2 +-
 drivers/gpu/drm/i915/i915_drv.c                |   5 +-
 drivers/gpu/drm/i915/i915_drv.h                |   1 +
 drivers/gpu/drm/radeon/radeon_pm.c             |   8 +-
 drivers/i2c/busses/i2c-brcmstb.c               |   3 +-
 drivers/iommu/amd_iommu_init.c                 |  63 +++++++--
 drivers/iommu/dmar.c                           |   5 +-
 drivers/iommu/intel-iommu.c                    |   4 +-
 drivers/media/i2c/adv7604.c                    |   3 +-
 drivers/misc/cxl/pci.c                         |   2 +-
 drivers/mtd/ubi/upd.c                          |   2 +-
 drivers/pci/host/pci-keystone-dw.c             |  11 +-
 drivers/sh/pm_runtime.c                        |   2 +-
 drivers/target/target_core_device.c            |  43 ++++++
 drivers/target/target_core_file.c              |  29 ++--
 drivers/target/target_core_iblock.c            |  56 ++------
 drivers/thermal/cpu_cooling.c                  |  14 +-
 drivers/usb/chipidea/otg.c                     |   2 +-
 drivers/usb/serial/cp210x.c                    |   1 +
 drivers/usb/serial/option.c                    |   5 +
 drivers/usb/serial/qcserial.c                  |   7 +-
 drivers/vfio/pci/vfio_pci.c                    |   9 +-
 drivers/vfio/platform/vfio_platform_common.c   |   9 +-
 drivers/vfio/vfio_iommu_type1.c                |   6 +-
 drivers/video/console/fbcon.c                  |   2 +
 fs/btrfs/async-thread.c                        |   2 +-
 fs/btrfs/ctree.h                               |   2 +-
 fs/btrfs/disk-io.c                             |   5 +-
 fs/btrfs/extent-tree.c                         |  13 +-
 fs/btrfs/inode.c                               |   4 -
 fs/btrfs/root-tree.c                           |  10 +-
 fs/cifs/cifsfs.h                               |  12 +-
 fs/cifs/cifssmb.c                              |  21 ++-
 fs/cifs/smb2pdu.c                              |  24 ++--
 fs/dcache.c                                    |  20 +--
 fs/fs-writeback.c                              |  54 ++++++--
 fs/jffs2/README.Locking                        |   5 +-
 fs/jffs2/build.c                               |  75 ++++++++---
 fs/jffs2/file.c                                |  39 +++---
 fs/jffs2/gc.c                                  |  17 ++-
 fs/jffs2/nodelist.h                            |   6 +-
 fs/super.c                                     |   1 +
 include/linux/ata.h                            |   4 +-
 include/linux/bio.h                            |  37 ++++++
 include/linux/blkdev.h                         |  23 +++-
 include/linux/dcache.h                         |   4 +-
 include/linux/libata.h                         |   2 +-
 include/linux/module.h                         |  17 +--
 include/linux/trace_events.h                   |   2 +
 include/linux/writeback.h                      |   5 +
 include/target/target_core_backend.h           |   3 +
 kernel/module.c                                | 112 ++++++++++------
 kernel/trace/trace_events.c                    |  14 +-
 kernel/trace/trace_events_filter.c             |  13 +-
 sound/core/control_compat.c                    |  90 ++++++++++---
 sound/core/pcm_compat.c                        | 177 ++++++++++++++++++++++++-
 sound/core/rawmidi_compat.c                    |  53 ++++++++
 sound/core/seq/oss/seq_oss.c                   |   2 -
 sound/core/seq/oss/seq_oss_device.h            |   1 -
 sound/core/seq/oss/seq_oss_init.c              |  16 ---
 sound/core/timer_compat.c                      |  18 ++-
 sound/pci/hda/patch_realtek.c                  |   1 +
 sound/pci/rme9652/hdsp.c                       |   4 +-
 sound/pci/rme9652/hdspm.c                      |  16 ++-
 sound/usb/quirks.c                             |   1 +
 91 files changed, 1000 insertions(+), 413 deletions(-)

[toc] | [next] | [standalone]


#1352398 — [PATCH 4.4 09/74] parisc: Fix ptrace syscall number and return value modification

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-03-08 01:30 +0100
Subject[PATCH 4.4 09/74] parisc: Fix ptrace syscall number and return value modification
Message-ID<radHc-1Il-13@gated-at.bofh.it>
In reply to#1352397
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Helge Deller <deller@gmx.de>

commit 98e8b6c9ac9d1b1e9d1122dfa6783d5d566bb8f7 upstream.

Mike Frysinger reported that his ptrace testcase showed strange
behaviour on parisc: It was not possible to avoid a syscall and the
return value of a syscall couldn't be changed.

To modify a syscall number, we were missing to save the new syscall
number to gr20 which is then picked up later in assembly again.

The effect that the return value couldn't be changed is a side-effect of
another bug in the assembly code. When a process is ptraced, userspace
expects each syscall to report entrance and exit of a syscall.  If a
syscall number was given which doesn't exist, we jumped to the normal
syscall exit code instead of informing userspace that the (non-existant)
syscall exits. This unexpected behaviour confuses userspace and thus the
bug was misinterpreted as if we can't change the return value.

This patch fixes both problems and was tested on 64bit kernel with
32bit userspace.

Signed-off-by: Helge Deller <deller@gmx.de>
Cc: Mike Frysinger <vapier@gentoo.org>
Tested-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/parisc/kernel/ptrace.c  |   16 +++++++++++-----
 arch/parisc/kernel/syscall.S |    5 ++++-
 2 files changed, 15 insertions(+), 6 deletions(-)

--- a/arch/parisc/kernel/ptrace.c
+++ b/arch/parisc/kernel/ptrace.c
@@ -269,14 +269,19 @@ long compat_arch_ptrace(struct task_stru
 
 long do_syscall_trace_enter(struct pt_regs *regs)
 {
-	long ret = 0;
-
 	/* Do the secure computing check first. */
 	secure_computing_strict(regs->gr[20]);
 
 	if (test_thread_flag(TIF_SYSCALL_TRACE) &&
-	    tracehook_report_syscall_entry(regs))
-		ret = -1L;
+	    tracehook_report_syscall_entry(regs)) {
+		/*
+		 * Tracing decided this syscall should not happen or the
+		 * debugger stored an invalid system call number. Skip
+		 * the system call and the system call restart handling.
+		 */
+		regs->gr[20] = -1UL;
+		goto out;
+	}
 
 #ifdef CONFIG_64BIT
 	if (!is_compat_task())
@@ -290,7 +295,8 @@ long do_syscall_trace_enter(struct pt_re
 			regs->gr[24] & 0xffffffff,
 			regs->gr[23] & 0xffffffff);
 
-	return ret ? : regs->gr[20];
+out:
+	return regs->gr[20];
 }
 
 void do_syscall_trace_exit(struct pt_regs *regs)
--- a/arch/parisc/kernel/syscall.S
+++ b/arch/parisc/kernel/syscall.S
@@ -343,7 +343,7 @@ tracesys_next:
 #endif
 
 	comiclr,>>=	__NR_Linux_syscalls, %r20, %r0
-	b,n	.Lsyscall_nosys
+	b,n	.Ltracesys_nosys
 
 	LDREGX  %r20(%r19), %r19
 
@@ -359,6 +359,9 @@ tracesys_next:
 	be      0(%sr7,%r19)
 	ldo	R%tracesys_exit(%r2),%r2
 
+.Ltracesys_nosys:
+	ldo	-ENOSYS(%r0),%r28		/* set errno */
+
 	/* Do *not* call this function on the gateway page, because it
 	makes a direct call to syscall_trace. */
 	

[toc] | [prev] | [next] | [standalone]


#1352399 — [PATCH 4.4 18/74] arm/arm64: KVM: Fix ioctl error handling

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-03-08 01:30 +0100
Subject[PATCH 4.4 18/74] arm/arm64: KVM: Fix ioctl error handling
Message-ID<radHc-1Il-15@gated-at.bofh.it>
In reply to#1352397
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Michael S. Tsirkin <mst@redhat.com>

commit 4cad67fca3fc952d6f2ed9e799621f07666a560f upstream.

Calling return copy_to_user(...) in an ioctl will not
do the right thing if there's a pagefault:
copy_to_user returns the number of bytes not copied
in this case.

Fix up kvm to do
	return copy_to_user(...)) ?  -EFAULT : 0;

everywhere.

Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm/kvm/guest.c   |    2 +-
 arch/arm64/kvm/guest.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -155,7 +155,7 @@ static int get_timer_reg(struct kvm_vcpu
 	u64 val;
 
 	val = kvm_arm_timer_get_reg(vcpu, reg->id);
-	return copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id));
+	return copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)) ? -EFAULT : 0;
 }
 
 static unsigned long num_core_regs(void)
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -186,7 +186,7 @@ static int get_timer_reg(struct kvm_vcpu
 	u64 val;
 
 	val = kvm_arm_timer_get_reg(vcpu, reg->id);
-	return copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id));
+	return copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)) ? -EFAULT : 0;
 }
 
 /**

[toc] | [prev] | [next] | [standalone]


#1352402 — [PATCH 4.4 10/74] mips/kvm: fix ioctl error handling

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-03-08 01:30 +0100
Subject[PATCH 4.4 10/74] mips/kvm: fix ioctl error handling
Message-ID<radHd-1Il-23@gated-at.bofh.it>
In reply to#1352397
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Michael S. Tsirkin <mst@redhat.com>

commit 0178fd7dcc4451fcb90bec5e91226586962478d2 upstream.

Returning directly whatever copy_to_user(...) or copy_from_user(...)
returns may not do the right thing if there's a pagefault:
copy_to_user/copy_from_user return the number of bytes not copied in
this case, but ioctls need to return -EFAULT instead.

Fix up kvm on mips to do
	return copy_to_user(...)) ?  -EFAULT : 0;
and
	return copy_from_user(...)) ?  -EFAULT : 0;

everywhere.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/mips/kvm/mips.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -702,7 +702,7 @@ static int kvm_mips_get_reg(struct kvm_v
 	} else if ((reg->id & KVM_REG_SIZE_MASK) == KVM_REG_SIZE_U128) {
 		void __user *uaddr = (void __user *)(long)reg->addr;
 
-		return copy_to_user(uaddr, vs, 16);
+		return copy_to_user(uaddr, vs, 16) ? -EFAULT : 0;
 	} else {
 		return -EINVAL;
 	}
@@ -732,7 +732,7 @@ static int kvm_mips_set_reg(struct kvm_v
 	} else if ((reg->id & KVM_REG_SIZE_MASK) == KVM_REG_SIZE_U128) {
 		void __user *uaddr = (void __user *)(long)reg->addr;
 
-		return copy_from_user(vs, uaddr, 16);
+		return copy_from_user(vs, uaddr, 16) ? -EFAULT : 0;
 	} else {
 		return -EINVAL;
 	}

[toc] | [prev] | [next] | [standalone]


#1352406 — [PATCH 4.4 12/74] fbcon: set a default value to blink interval

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-03-08 01:30 +0100
Subject[PATCH 4.4 12/74] fbcon: set a default value to blink interval
Message-ID<radHd-1Il-35@gated-at.bofh.it>
In reply to#1352397
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>

commit a1e533ec07d583d01349ef13c0c965b8633e1b91 upstream.

Since commit 27a4c827c34ac4256a190cc9d24607f953c1c459
	fbcon: use the cursor blink interval provided by vt

two attempts have been made at fixing a possible hang caused by
cursor_timer_handler. That function registers a timer to be triggered at
"jiffies + fbcon_ops.cur_blink_jiffies".

A new case had been encountered during initialisation of clcd-pl11x:

    fbcon_fb_registered
    do_fbcon_takeover

    ->  do_register_con_driver
        fbcon_startup
    (A) add_cursor_timer (with cur_blink_jiffies = 0)

    ->  do_bind_con_driver
        visual_init
        fbcon_init
    (B) cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);

If we take an softirq anywhere between A and B (and we do),
cursor_timer_handler executes indefinitely.

Instead of patching all possible paths that lead to this case one at a
time, fix the issue at the source and initialise cur_blink_jiffies to
200ms when allocating fbcon_ops. This was its default value before
aforesaid commit. fbcon_cursor or fbcon_init will refine this value
downstream.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Tested-by: Scot Doyle <lkml14@scotdoyle.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/video/console/fbcon.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -709,6 +709,7 @@ static int con2fb_acquire_newinfo(struct
 	}
 
 	if (!err) {
+		ops->cur_blink_jiffies = HZ / 5;
 		info->fbcon_par = ops;
 
 		if (vc)
@@ -956,6 +957,7 @@ static const char *fbcon_startup(void)
 	ops->currcon = -1;
 	ops->graphics = 1;
 	ops->cur_rotate = -1;
+	ops->cur_blink_jiffies = HZ / 5;
 	info->fbcon_par = ops;
 	p->con_rotate = initial_rotation;
 	set_blitting_type(vc, info);

[toc] | [prev] | [next] | [standalone]


#1352410 — [PATCH 4.4 03/74] Btrfs: fix deadlock running delayed iputs at transaction commit time

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-03-08 01:30 +0100
Subject[PATCH 4.4 03/74] Btrfs: fix deadlock running delayed iputs at transaction commit time
Message-ID<radHd-1Il-39@gated-at.bofh.it>
In reply to#1352397
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Filipe Manana <fdmanana@suse.com>

commit c2d6cb1636d235257086f939a8194ef0bf93af6e upstream.

While running a stress test I ran into a deadlock when running the delayed
iputs at transaction time, which produced the following report and trace:

[  886.399989] =============================================
[  886.400871] [ INFO: possible recursive locking detected ]
[  886.401663] 4.4.0-rc6-btrfs-next-18+ #1 Not tainted
[  886.402384] ---------------------------------------------
[  886.403182] fio/8277 is trying to acquire lock:
[  886.403568]  (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
[  886.403568]
[  886.403568] but task is already holding lock:
[  886.403568]  (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
[  886.403568]
[  886.403568] other info that might help us debug this:
[  886.403568]  Possible unsafe locking scenario:
[  886.403568]
[  886.403568]        CPU0
[  886.403568]        ----
[  886.403568]   lock(&fs_info->delayed_iput_sem);
[  886.403568]   lock(&fs_info->delayed_iput_sem);
[  886.403568]
[  886.403568]  *** DEADLOCK ***
[  886.403568]
[  886.403568]  May be due to missing lock nesting notation
[  886.403568]
[  886.403568] 3 locks held by fio/8277:
[  886.403568]  #0:  (sb_writers#11){.+.+.+}, at: [<ffffffff81174c4c>] __sb_start_write+0x5f/0xb0
[  886.403568]  #1:  (&sb->s_type->i_mutex_key#15){+.+.+.}, at: [<ffffffffa054620d>] btrfs_file_write_iter+0x73/0x408 [btrfs]
[  886.403568]  #2:  (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
[  886.403568]
[  886.403568] stack backtrace:
[  886.403568] CPU: 6 PID: 8277 Comm: fio Not tainted 4.4.0-rc6-btrfs-next-18+ #1
[  886.403568] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
[  886.403568]  0000000000000000 ffff88009f80f770 ffffffff8125d4fd ffffffff82af1fc0
[  886.403568]  ffff88009f80f830 ffffffff8108e5f9 0000000200000000 ffff88009fd92290
[  886.403568]  0000000000000000 ffffffff82af1fc0 ffffffff829cfb01 00042b216d008804
[  886.403568] Call Trace:
[  886.403568]  [<ffffffff8125d4fd>] dump_stack+0x4e/0x79
[  886.403568]  [<ffffffff8108e5f9>] __lock_acquire+0xd42/0xf0b
[  886.403568]  [<ffffffff810c22db>] ? __module_address+0xdf/0x108
[  886.403568]  [<ffffffff8108eb77>] lock_acquire+0x10d/0x194
[  886.403568]  [<ffffffff8108eb77>] ? lock_acquire+0x10d/0x194
[  886.403568]  [<ffffffffa0538823>] ? btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
[  886.489542]  [<ffffffff8148556b>] down_read+0x3e/0x4d
[  886.489542]  [<ffffffffa0538823>] ? btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
[  886.489542]  [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
[  886.489542]  [<ffffffffa0533953>] btrfs_commit_transaction+0x8f5/0x96e [btrfs]
[  886.489542]  [<ffffffffa0521d7a>] flush_space+0x435/0x44a [btrfs]
[  886.489542]  [<ffffffffa052218b>] ? reserve_metadata_bytes+0x26a/0x384 [btrfs]
[  886.489542]  [<ffffffffa05221ae>] reserve_metadata_bytes+0x28d/0x384 [btrfs]
[  886.489542]  [<ffffffffa052256c>] ? btrfs_block_rsv_refill+0x58/0x96 [btrfs]
[  886.489542]  [<ffffffffa0522584>] btrfs_block_rsv_refill+0x70/0x96 [btrfs]
[  886.489542]  [<ffffffffa053d747>] btrfs_evict_inode+0x394/0x55a [btrfs]
[  886.489542]  [<ffffffff81188e31>] evict+0xa7/0x15c
[  886.489542]  [<ffffffff81189878>] iput+0x1d3/0x266
[  886.489542]  [<ffffffffa053887c>] btrfs_run_delayed_iputs+0x8f/0xbf [btrfs]
[  886.489542]  [<ffffffffa0533953>] btrfs_commit_transaction+0x8f5/0x96e [btrfs]
[  886.489542]  [<ffffffff81085096>] ? signal_pending_state+0x31/0x31
[  886.489542]  [<ffffffffa0521191>] btrfs_alloc_data_chunk_ondemand+0x1d7/0x288 [btrfs]
[  886.489542]  [<ffffffffa0521282>] btrfs_check_data_free_space+0x40/0x59 [btrfs]
[  886.489542]  [<ffffffffa05228f5>] btrfs_delalloc_reserve_space+0x1e/0x4e [btrfs]
[  886.489542]  [<ffffffffa053620a>] btrfs_direct_IO+0x10c/0x27e [btrfs]
[  886.489542]  [<ffffffff8111d9a1>] generic_file_direct_write+0xb3/0x128
[  886.489542]  [<ffffffffa05463c3>] btrfs_file_write_iter+0x229/0x408 [btrfs]
[  886.489542]  [<ffffffff8108ae38>] ? __lock_is_held+0x38/0x50
[  886.489542]  [<ffffffff8117279e>] __vfs_write+0x7c/0xa5
[  886.489542]  [<ffffffff81172cda>] vfs_write+0xa0/0xe4
[  886.489542]  [<ffffffff811734cc>] SyS_write+0x50/0x7e
[  886.489542]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
[ 1081.852335] INFO: task fio:8244 blocked for more than 120 seconds.
[ 1081.854348]       Not tainted 4.4.0-rc6-btrfs-next-18+ #1
[ 1081.857560] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1081.863227] fio        D ffff880213f9bb28     0  8244   8240 0x00000000
[ 1081.868719]  ffff880213f9bb28 00ffffff810fc6b0 ffffffff0000000a ffff88023ed55240
[ 1081.872499]  ffff880206b5d400 ffff880213f9c000 ffff88020a4d5318 ffff880206b5d400
[ 1081.876834]  ffffffff00000001 ffff880206b5d400 ffff880213f9bb40 ffffffff81482ba4
[ 1081.880782] Call Trace:
[ 1081.881793]  [<ffffffff81482ba4>] schedule+0x7f/0x97
[ 1081.883340]  [<ffffffff81485eb5>] rwsem_down_write_failed+0x2d5/0x325
[ 1081.895525]  [<ffffffff8108d48d>] ? trace_hardirqs_on_caller+0x16/0x1ab
[ 1081.897419]  [<ffffffff81269723>] call_rwsem_down_write_failed+0x13/0x20
[ 1081.899251]  [<ffffffff81269723>] ? call_rwsem_down_write_failed+0x13/0x20
[ 1081.901063]  [<ffffffff81089fae>] ? __down_write_nested.isra.0+0x1f/0x21
[ 1081.902365]  [<ffffffff814855bd>] down_write+0x43/0x57
[ 1081.903846]  [<ffffffffa05211b0>] ? btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]
[ 1081.906078]  [<ffffffffa05211b0>] btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]
[ 1081.908846]  [<ffffffff8108d461>] ? mark_held_locks+0x56/0x6c
[ 1081.910409]  [<ffffffffa0521282>] btrfs_check_data_free_space+0x40/0x59 [btrfs]
[ 1081.912482]  [<ffffffffa05228f5>] btrfs_delalloc_reserve_space+0x1e/0x4e [btrfs]
[ 1081.914597]  [<ffffffffa053620a>] btrfs_direct_IO+0x10c/0x27e [btrfs]
[ 1081.919037]  [<ffffffff8111d9a1>] generic_file_direct_write+0xb3/0x128
[ 1081.920754]  [<ffffffffa05463c3>] btrfs_file_write_iter+0x229/0x408 [btrfs]
[ 1081.922496]  [<ffffffff8108ae38>] ? __lock_is_held+0x38/0x50
[ 1081.923922]  [<ffffffff8117279e>] __vfs_write+0x7c/0xa5
[ 1081.925275]  [<ffffffff81172cda>] vfs_write+0xa0/0xe4
[ 1081.926584]  [<ffffffff811734cc>] SyS_write+0x50/0x7e
[ 1081.927968]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
[ 1081.985293] INFO: lockdep is turned off.
[ 1081.986132] INFO: task fio:8249 blocked for more than 120 seconds.
[ 1081.987434]       Not tainted 4.4.0-rc6-btrfs-next-18+ #1
[ 1081.988534] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1081.990147] fio        D ffff880218febbb8     0  8249   8240 0x00000000
[ 1081.991626]  ffff880218febbb8 00ffffff81486b8e ffff88020000000b ffff88023ed75240
[ 1081.993258]  ffff8802120a9a00 ffff880218fec000 ffff88020a4d5318 ffff8802120a9a00
[ 1081.994850]  ffffffff00000001 ffff8802120a9a00 ffff880218febbd0 ffffffff81482ba4
[ 1081.996485] Call Trace:
[ 1081.997037]  [<ffffffff81482ba4>] schedule+0x7f/0x97
[ 1081.998017]  [<ffffffff81485eb5>] rwsem_down_write_failed+0x2d5/0x325
[ 1081.999241]  [<ffffffff810852a5>] ? finish_wait+0x6d/0x76
[ 1082.000306]  [<ffffffff81269723>] call_rwsem_down_write_failed+0x13/0x20
[ 1082.001533]  [<ffffffff81269723>] ? call_rwsem_down_write_failed+0x13/0x20
[ 1082.002776]  [<ffffffff81089fae>] ? __down_write_nested.isra.0+0x1f/0x21
[ 1082.003995]  [<ffffffff814855bd>] down_write+0x43/0x57
[ 1082.005000]  [<ffffffffa05211b0>] ? btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]
[ 1082.007403]  [<ffffffffa05211b0>] btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]
[ 1082.008988]  [<ffffffffa0545064>] btrfs_fallocate+0x7c1/0xc2f [btrfs]
[ 1082.010193]  [<ffffffff8108a1ba>] ? percpu_down_read+0x4e/0x77
[ 1082.011280]  [<ffffffff81174c4c>] ? __sb_start_write+0x5f/0xb0
[ 1082.012265]  [<ffffffff81174c4c>] ? __sb_start_write+0x5f/0xb0
[ 1082.013021]  [<ffffffff811712e4>] vfs_fallocate+0x170/0x1ff
[ 1082.013738]  [<ffffffff81181ebb>] ioctl_preallocate+0x89/0x9b
[ 1082.014778]  [<ffffffff811822d7>] do_vfs_ioctl+0x40a/0x4ea
[ 1082.015778]  [<ffffffff81176ea7>] ? SYSC_newfstat+0x25/0x2e
[ 1082.016806]  [<ffffffff8118b4de>] ? __fget_light+0x4d/0x71
[ 1082.017789]  [<ffffffff8118240e>] SyS_ioctl+0x57/0x79
[ 1082.018706]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f

This happens because we can recursively acquire the semaphore
fs_info->delayed_iput_sem when attempting to allocate space to satisfy
a file write request as shown in the first trace above - when committing
a transaction we acquire (down_read) the semaphore before running the
delayed iputs, and when running a delayed iput() we can end up calling
an inode's eviction handler, which in turn commits another transaction
and attempts to acquire (down_read) again the semaphore to run more
delayed iput operations.
This results in a deadlock because if a task acquires multiple times a
semaphore it should invoke down_read_nested() with a different lockdep
class for each level of recursion.

Fix this by simplifying the implementation and use a mutex instead that
is acquired by the cleaner kthread before it runs the delayed iputs
instead of always acquiring a semaphore before delayed references are
run from anywhere.

Fixes: d7c151717a1e (btrfs: Fix NO_SPACE bug caused by delayed-iput)
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/btrfs/ctree.h       |    2 +-
 fs/btrfs/disk-io.c     |    5 ++++-
 fs/btrfs/extent-tree.c |    9 +++++----
 fs/btrfs/inode.c       |    4 ----
 4 files changed, 10 insertions(+), 10 deletions(-)

--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1572,7 +1572,7 @@ struct btrfs_fs_info {
 
 	spinlock_t delayed_iput_lock;
 	struct list_head delayed_iputs;
-	struct rw_semaphore delayed_iput_sem;
+	struct mutex cleaner_delayed_iput_mutex;
 
 	/* this protects tree_mod_seq_list */
 	spinlock_t tree_mod_seq_lock;
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1796,7 +1796,10 @@ static int cleaner_kthread(void *arg)
 			goto sleep;
 		}
 
+		mutex_lock(&root->fs_info->cleaner_delayed_iput_mutex);
 		btrfs_run_delayed_iputs(root);
+		mutex_unlock(&root->fs_info->cleaner_delayed_iput_mutex);
+
 		again = btrfs_clean_one_deleted_snapshot(root);
 		mutex_unlock(&root->fs_info->cleaner_mutex);
 
@@ -2556,8 +2559,8 @@ int open_ctree(struct super_block *sb,
 	mutex_init(&fs_info->delete_unused_bgs_mutex);
 	mutex_init(&fs_info->reloc_mutex);
 	mutex_init(&fs_info->delalloc_root_mutex);
+	mutex_init(&fs_info->cleaner_delayed_iput_mutex);
 	seqlock_init(&fs_info->profiles_lock);
-	init_rwsem(&fs_info->delayed_iput_sem);
 
 	INIT_LIST_HEAD(&fs_info->dirty_cowonly_roots);
 	INIT_LIST_HEAD(&fs_info->space_info);
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4100,11 +4100,12 @@ commit_trans:
 				if (ret)
 					return ret;
 				/*
-				 * make sure that all running delayed iput are
-				 * done
+				 * The cleaner kthread might still be doing iput
+				 * operations. Wait for it to finish so that
+				 * more space is released.
 				 */
-				down_write(&root->fs_info->delayed_iput_sem);
-				up_write(&root->fs_info->delayed_iput_sem);
+				mutex_lock(&root->fs_info->cleaner_delayed_iput_mutex);
+				mutex_unlock(&root->fs_info->cleaner_delayed_iput_mutex);
 				goto again;
 			} else {
 				btrfs_end_transaction(trans, root);
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -3142,8 +3142,6 @@ void btrfs_run_delayed_iputs(struct btrf
 	if (empty)
 		return;
 
-	down_read(&fs_info->delayed_iput_sem);
-
 	spin_lock(&fs_info->delayed_iput_lock);
 	list_splice_init(&fs_info->delayed_iputs, &list);
 	spin_unlock(&fs_info->delayed_iput_lock);
@@ -3154,8 +3152,6 @@ void btrfs_run_delayed_iputs(struct btrf
 		iput(delayed->inode);
 		kfree(delayed);
 	}
-
-	up_read(&root->fs_info->delayed_iput_sem);
 }
 
 /*

[toc] | [prev] | [next] | [standalone]


#1352413 — [PATCH 4.4 07/74] block: Initialize max_dev_sectors to 0

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-03-08 01:30 +0100
Subject[PATCH 4.4 07/74] block: Initialize max_dev_sectors to 0
Message-ID<radHe-1Il-49@gated-at.bofh.it>
In reply to#1352397
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Keith Busch <keith.busch@intel.com>

commit 5f009d3f8e6685fe8c6215082c1696a08b411220 upstream.

The new queue limit is not used by the majority of block drivers, and
should be initialized to 0 for the driver's requested settings to be used.

Signed-off-by: Keith Busch <keith.busch@intel.com>
Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 block/blk-settings.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -91,8 +91,8 @@ void blk_set_default_limits(struct queue
 	lim->seg_boundary_mask = BLK_SEG_BOUNDARY_MASK;
 	lim->virt_boundary_mask = 0;
 	lim->max_segment_size = BLK_MAX_SEGMENT_SIZE;
-	lim->max_sectors = lim->max_dev_sectors = lim->max_hw_sectors =
-		BLK_SAFE_MAX_SECTORS;
+	lim->max_sectors = lim->max_hw_sectors = BLK_SAFE_MAX_SECTORS;
+	lim->max_dev_sectors = 0;
 	lim->chunk_sectors = 0;
 	lim->max_write_same_sectors = 0;
 	lim->max_discard_sectors = 0;

[toc] | [prev] | [next] | [standalone]


#1352414 — [PATCH 4.4 16/74] vfio: fix ioctl error handling

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-03-08 01:30 +0100
Subject[PATCH 4.4 16/74] vfio: fix ioctl error handling
Message-ID<radHe-1Il-47@gated-at.bofh.it>
In reply to#1352397
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Michael S. Tsirkin <mst@redhat.com>

commit 8160c4e455820d5008a1116d2dca35f0363bb062 upstream.

Calling return copy_to_user(...) in an ioctl will not
do the right thing if there's a pagefault:
copy_to_user returns the number of bytes not copied
in this case.

Fix up vfio to do
	return copy_to_user(...)) ?
		-EFAULT : 0;

everywhere.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/vfio/pci/vfio_pci.c                  |    9 ++++++---
 drivers/vfio/platform/vfio_platform_common.c |    9 ++++++---
 drivers/vfio/vfio_iommu_type1.c              |    6 ++++--
 3 files changed, 16 insertions(+), 8 deletions(-)

--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -446,7 +446,8 @@ static long vfio_pci_ioctl(void *device_
 		info.num_regions = VFIO_PCI_NUM_REGIONS;
 		info.num_irqs = VFIO_PCI_NUM_IRQS;
 
-		return copy_to_user((void __user *)arg, &info, minsz);
+		return copy_to_user((void __user *)arg, &info, minsz) ?
+			-EFAULT : 0;
 
 	} else if (cmd == VFIO_DEVICE_GET_REGION_INFO) {
 		struct pci_dev *pdev = vdev->pdev;
@@ -520,7 +521,8 @@ static long vfio_pci_ioctl(void *device_
 			return -EINVAL;
 		}
 
-		return copy_to_user((void __user *)arg, &info, minsz);
+		return copy_to_user((void __user *)arg, &info, minsz) ?
+			-EFAULT : 0;
 
 	} else if (cmd == VFIO_DEVICE_GET_IRQ_INFO) {
 		struct vfio_irq_info info;
@@ -555,7 +557,8 @@ static long vfio_pci_ioctl(void *device_
 		else
 			info.flags |= VFIO_IRQ_INFO_NORESIZE;
 
-		return copy_to_user((void __user *)arg, &info, minsz);
+		return copy_to_user((void __user *)arg, &info, minsz) ?
+			-EFAULT : 0;
 
 	} else if (cmd == VFIO_DEVICE_SET_IRQS) {
 		struct vfio_irq_set hdr;
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -219,7 +219,8 @@ static long vfio_platform_ioctl(void *de
 		info.num_regions = vdev->num_regions;
 		info.num_irqs = vdev->num_irqs;
 
-		return copy_to_user((void __user *)arg, &info, minsz);
+		return copy_to_user((void __user *)arg, &info, minsz) ?
+			-EFAULT : 0;
 
 	} else if (cmd == VFIO_DEVICE_GET_REGION_INFO) {
 		struct vfio_region_info info;
@@ -240,7 +241,8 @@ static long vfio_platform_ioctl(void *de
 		info.size = vdev->regions[info.index].size;
 		info.flags = vdev->regions[info.index].flags;
 
-		return copy_to_user((void __user *)arg, &info, minsz);
+		return copy_to_user((void __user *)arg, &info, minsz) ?
+			-EFAULT : 0;
 
 	} else if (cmd == VFIO_DEVICE_GET_IRQ_INFO) {
 		struct vfio_irq_info info;
@@ -259,7 +261,8 @@ static long vfio_platform_ioctl(void *de
 		info.flags = vdev->irqs[info.index].flags;
 		info.count = vdev->irqs[info.index].count;
 
-		return copy_to_user((void __user *)arg, &info, minsz);
+		return copy_to_user((void __user *)arg, &info, minsz) ?
+			-EFAULT : 0;
 
 	} else if (cmd == VFIO_DEVICE_SET_IRQS) {
 		struct vfio_irq_set hdr;
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -999,7 +999,8 @@ static long vfio_iommu_type1_ioctl(void
 
 		info.iova_pgsizes = vfio_pgsize_bitmap(iommu);
 
-		return copy_to_user((void __user *)arg, &info, minsz);
+		return copy_to_user((void __user *)arg, &info, minsz) ?
+			-EFAULT : 0;
 
 	} else if (cmd == VFIO_IOMMU_MAP_DMA) {
 		struct vfio_iommu_type1_dma_map map;
@@ -1032,7 +1033,8 @@ static long vfio_iommu_type1_ioctl(void
 		if (ret)
 			return ret;
 
-		return copy_to_user((void __user *)arg, &unmap, minsz);
+		return copy_to_user((void __user *)arg, &unmap, minsz) ?
+			-EFAULT : 0;
 	}
 
 	return -ENOTTY;

[toc] | [prev] | [next] | [standalone]


#1352934

FromGuenter Roeck <linux@roeck-us.net>
Date2016-03-08 12:50 +0100
Message-ID<raojh-hv-39@gated-at.bofh.it>
In reply to#1352397
On Mon, Mar 07, 2016 at 04:02:25PM -0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.5 release.
> There are 74 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu Mar 10 00:02:56 UTC 2016.
> Anything received after that time might be too late.
> 
Build results:
	total: 145 pass: 145 fail: 0
Qemu test results:
	total: 96 pass: 96 fail: 0

Detaila are available at http://kerneltests.org/builders.

Guenter

[toc] | [prev] | [next] | [standalone]


#1353089

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-03-08 15:20 +0100
Message-ID<raqEq-1XQ-23@gated-at.bofh.it>
In reply to#1352934
On Tue, Mar 08, 2016 at 03:45:59AM -0800, Guenter Roeck wrote:
> On Mon, Mar 07, 2016 at 04:02:25PM -0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.5 release.
> > There are 74 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu Mar 10 00:02:56 UTC 2016.
> > Anything received after that time might be too late.
> > 
> Build results:
> 	total: 145 pass: 145 fail: 0
> Qemu test results:
> 	total: 96 pass: 96 fail: 0
> 
> Detaila are available at http://kerneltests.org/builders.

Thanks for testing all of these and letting me know.

greg k-h

[toc] | [prev] | [next] | [standalone]


#1353106

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-03-08 15:40 +0100
Message-ID<raqXM-25J-11@gated-at.bofh.it>
In reply to#1352397
On Tue, Mar 08, 2016 at 02:11:08AM -0800, kernelci.org bot wrote:
> stable-queue boot: 205 boots: 14 failed, 190 passed with 1 offline (v4.4.4-74-gcc3ba9c14b31)
> 
> Full Boot Summary: https://kernelci.org/boot/all/job/stable-queue/kernel/v4.4.4-74-gcc3ba9c14b31/
> Full Build Summary: https://kernelci.org/build/stable-queue/kernel/v4.4.4-74-gcc3ba9c14b31/
> 
> Tree: stable-queue
> Branch: local/linux-4.4.y.queue
> Git Describe: v4.4.4-74-gcc3ba9c14b31
> Git Commit: cc3ba9c14b31161587ce85e9b5d642e730a2d0e8
> Git URL: git://server.roeck-us.net/git/linux-stable.git
> Tested: 47 unique boards, 13 SoC families, 18 builds out of 132
> 
> Boot Failures Detected: https://kernelci.org/boot/?v4.4.4-74-gcc3ba9c14b31&fail
> 
> arm:
> 
>     mxs_defconfig:
>         imx23-olinuxino: 1 failed lab
> 
>     omap2plus_defconfig:
>         omap4-panda: 1 failed lab
> 
>     multi_v7_defconfig+CONFIG_LKDTM=y:
>         imx53-qsrb: 1 failed lab
>         imx6dl-riotboard: 1 failed lab
>         socfpga_cyclone5_socrates: 1 failed lab
> 
>     multi_v7_defconfig+CONFIG_SMP=n:
>         imx53-qsrb: 1 failed lab
>         imx6dl-riotboard: 1 failed lab
>         socfpga_cyclone5_socrates: 1 failed lab
> 
>     multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y:
>         socfpga_cyclone5_socrates: 1 failed lab
> 
>     imx_v6_v7_defconfig:
>         imx53-qsrb: 1 failed lab
>         imx6dl-riotboard: 1 failed lab
> 
>     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
>         imx53-qsrb: 1 failed lab
>         imx6dl-riotboard: 1 failed lab
>         socfpga_cyclone5_socrates: 1 failed lab
> 
> Offline Platforms:
> 
> arm:
> 
>     mxs_defconfig:
>         imx28-duckbill: 1 offline lab

I really don't know what these mean, any chance you can distill these
down to "all is fine", or "there is a problem with this arch" type
emails?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]


#1353821

FromKevin Hilman <khilman@baylibre.com>
Date2016-03-09 06:40 +0100
Message-ID<raF0L-3nW-35@gated-at.bofh.it>
In reply to#1353106
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:

> On Tue, Mar 08, 2016 at 02:11:08AM -0800, kernelci.org bot wrote:
>> stable-queue boot: 205 boots: 14 failed, 190 passed with 1 offline (v4.4.4-74-gcc3ba9c14b31)
>> 
>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-queue/kernel/v4.4.4-74-gcc3ba9c14b31/
>> Full Build Summary: https://kernelci.org/build/stable-queue/kernel/v4.4.4-74-gcc3ba9c14b31/
>> 
>> Tree: stable-queue
>> Branch: local/linux-4.4.y.queue
>> Git Describe: v4.4.4-74-gcc3ba9c14b31
>> Git Commit: cc3ba9c14b31161587ce85e9b5d642e730a2d0e8
>> Git URL: git://server.roeck-us.net/git/linux-stable.git
>> Tested: 47 unique boards, 13 SoC families, 18 builds out of 132
>> 
>> Boot Failures Detected: https://kernelci.org/boot/?v4.4.4-74-gcc3ba9c14b31&fail
>> 
>> arm:
>> 
>>     mxs_defconfig:
>>         imx23-olinuxino: 1 failed lab
>> 
>>     omap2plus_defconfig:
>>         omap4-panda: 1 failed lab
>> 
>>     multi_v7_defconfig+CONFIG_LKDTM=y:
>>         imx53-qsrb: 1 failed lab
>>         imx6dl-riotboard: 1 failed lab
>>         socfpga_cyclone5_socrates: 1 failed lab
>> 
>>     multi_v7_defconfig+CONFIG_SMP=n:
>>         imx53-qsrb: 1 failed lab
>>         imx6dl-riotboard: 1 failed lab
>>         socfpga_cyclone5_socrates: 1 failed lab
>> 
>>     multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y:
>>         socfpga_cyclone5_socrates: 1 failed lab
>> 
>>     imx_v6_v7_defconfig:
>>         imx53-qsrb: 1 failed lab
>>         imx6dl-riotboard: 1 failed lab
>> 
>>     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
>>         imx53-qsrb: 1 failed lab
>>         imx6dl-riotboard: 1 failed lab
>>         socfpga_cyclone5_socrates: 1 failed lab
>> 
>> Offline Platforms:
>> 
>> arm:
>> 
>>     mxs_defconfig:
>>         imx28-duckbill: 1 offline lab
>
> I really don't know what these mean, any chance you can distill these
> down to "all is fine", or "there is a problem with this arch" type
> emails?

All is fine.

These failures are are on newly added boards coming from a new lab and
they're failing in other trees also, so we'll ignore them for now and
check with the specific lab owner.

Kevin

[toc] | [prev] | [next] | [standalone]


#1353194

FromShuah Khan <shuahkh@osg.samsung.com>
Date2016-03-08 17:30 +0100
Message-ID<rasGe-3hq-17@gated-at.bofh.it>
In reply to#1352397
On 03/07/2016 05:02 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.5 release.
> There are 74 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu Mar 10 00:02:56 UTC 2016.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
> 	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.5-rc1.gz
> and the diffstat can be found below.
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978

[toc] | [prev] | [next] | [standalone]


#1353720

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-03-09 03:10 +0100
Message-ID<raBJw-1cq-1@gated-at.bofh.it>
In reply to#1353194
On Tue, Mar 08, 2016 at 09:24:17AM -0700, Shuah Khan wrote:
> On 03/07/2016 05:02 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.5 release.
> > There are 74 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu Mar 10 00:02:56 UTC 2016.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.5-rc1.gz
> > and the diffstat can be found below.
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web