1. 01 May, 2018 24 commits
  2. 29 Apr, 2018 16 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.14.38 · a87463f7
      Greg Kroah-Hartman authored
      a87463f7
    • Hans de Goede's avatar
      ACPI / video: Only default only_lcd to true on Win8-ready _desktops_ · 3e491587
      Hans de Goede authored
      commit 53fa1f6e upstream.
      
      Commit 5928c281 (ACPI / video: Default lcd_only to true on Win8-ready
      and newer machines) made only_lcd default to true on all machines where
      acpi_osi_is_win8() returns true, including laptops.
      
      The purpose of this is to avoid the bogus / non-working acpi backlight
      interface which many newer BIOS-es define on desktop machines.
      
      But this is causing a regression on some laptops, specifically on the
      Dell XPS 13 2013 model, which does not have the LCD flag set for its
      fully functional ACPI backlight interface.
      
      Rather then DMI quirking our way out of this, this commits changes the
      logic for setting only_lcd to true, to only do this on machines with
      a desktop (or server) dmi chassis-type.
      
      Note that we cannot simply only check the chassis-type and not register
      the backlight interface based on that as there are some laptops and
      tablets which have their chassis-type set to "3" aka desktop. Hopefully
      the combination of checking the LCD flag, but only on devices with
      a desktop(ish) chassis-type will avoid the needs for DMI quirks for this,
      or at least limit the amount of DMI quirks which we need to a minimum.
      
      Fixes: 5928c281 (ACPI / video: Default lcd_only to true on Win8-ready and newer machines)
      Reported-and-tested-by: default avatarJames Hogan <jhogan@kernel.org>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Cc: 4.15+ <stable@vger.kernel.org> # 4.15+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e491587
    • Heiko Carstens's avatar
      s390/uprobes: implement arch_uretprobe_is_alive() · c371fe01
      Heiko Carstens authored
      commit 783c3b53 upstream.
      
      Implement s390 specific arch_uretprobe_is_alive() to avoid SIGSEGVs
      observed with uretprobes in combination with setjmp/longjmp.
      
      See commit 2dea1d9c ("powerpc/uprobes: Implement
      arch_uretprobe_is_alive()") for more details.
      
      With this implemented all test cases referenced in the above commit
      pass.
      Reported-by: default avatarZiqian SUN <zsun@redhat.com>
      Cc: <stable@vger.kernel.org> # v4.3+
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c371fe01
    • Stefan Haberland's avatar
      s390/dasd: fix IO error for newly defined devices · 5dad5105
      Stefan Haberland authored
      commit 5d27a2bf upstream.
      
      When a new CKD storage volume is defined at the storage server, Linux
      may be relying on outdated information about that volume, which leads to
      the following errors:
      
      1. Command Reject Errors for minidisk on z/VM:
      
      dasd-eckd.b3193d: 0.0.XXXX: An error occurred in the DASD device driver,
      		  reason=09
      dasd(eckd): I/O status report for device 0.0.XXXX:
      dasd(eckd): in req: 00000000XXXXXXXX CC:00 FC:04 AC:00 SC:17 DS:02 CS:00
      	    RC:0
      dasd(eckd): device 0.0.2046: Failing CCW: 00000000XXXXXXXX
      dasd(eckd): Sense(hex)  0- 7: 80 00 00 00 00 00 00 00
      dasd(eckd): Sense(hex)  8-15: 00 00 00 00 00 00 00 00
      dasd(eckd): Sense(hex) 16-23: 00 00 00 00 e1 00 0f 00
      dasd(eckd): Sense(hex) 24-31: 00 00 40 e2 00 00 00 00
      dasd(eckd): 24 Byte: 0 MSG 0, no MSGb to SYSOP
      
      2. Equipment Check errors on LPAR or for dedicated devices on z/VM:
      
      dasd(eckd): I/O status report for device 0.0.XXXX:
      dasd(eckd): in req: 00000000XXXXXXXX CC:00 FC:04 AC:00 SC:17 DS:0E CS:40
      	    fcxs:01 schxs:00 RC:0
      dasd(eckd): device 0.0.9713: Failing TCW: 00000000XXXXXXXX
      dasd(eckd): Sense(hex)  0- 7: 10 00 00 00 13 58 4d 0f
      dasd(eckd): Sense(hex)  8-15: 67 00 00 00 00 00 00 04
      dasd(eckd): Sense(hex) 16-23: e5 18 05 33 97 01 0f 0f
      dasd(eckd): Sense(hex) 24-31: 00 00 40 e2 00 04 58 0d
      dasd(eckd): 24 Byte: 0 MSG f, no MSGb to SYSOP
      
      Fix this problem by using the up-to-date information provided during
      online processing via the device specific SNEQ to detect the case of
      outdated LCU data. If there is a difference, perform a re-read of that
      data.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarJan Hoeppner <hoeppner@linux.ibm.com>
      Signed-off-by: default avatarStefan Haberland <sth@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5dad5105
    • Sebastian Ott's avatar
      s390/cio: update chpid descriptor after resource accessibility event · 3b5c2e1d
      Sebastian Ott authored
      commit af2e460a upstream.
      
      Channel path descriptors have been seen as something stable (as
      long as the chpid is configured). Recent tests have shown that the
      descriptor can also be altered when the link state of a channel path
      changes. Thus it is necessary to update the descriptor during
      handling of resource accessibility events.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarSebastian Ott <sebott@linux.ibm.com>
      Reviewed-by: default avatarPeter Oberparleiter <oberpar@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3b5c2e1d
    • Peter Xu's avatar
      tracing: Fix missing tab for hwlat_detector print format · a75bf6f7
      Peter Xu authored
      commit 9a0fd675 upstream.
      
      It's been missing for a while but no one is touching that up.  Fix it.
      
      Link: http://lkml.kernel.org/r/20180315060639.9578-1-peterx@redhat.com
      
      CC: Ingo Molnar <mingo@kernel.org>
      Cc:stable@vger.kernel.org
      Fixes: 7b2c8625 ("tracing: Add NMI tracing in hwlat detector")
      Signed-off-by: default avatarPeter Xu <peterx@redhat.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a75bf6f7
    • Finn Thain's avatar
      block/swim: Fix IO error at end of medium · d82923c0
      Finn Thain authored
      commit 5a13388d upstream.
      
      Reading to the end of a 720K disk results in an IO error instead of EOF
      because the block layer thinks the disk has 2880 sectors. (Partly this
      is a result of inverted logic of the ONEMEG_MEDIA bit that's now fixed.)
      
      Initialize the density and head count in swim_add_floppy() to agree
      with the device size passed to set_capacity() during drive probe.
      
      Call set_capacity() again upon device open, after refreshing the density
      and head count values.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: stable@vger.kernel.org # v4.14+
      Tested-by: default avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d82923c0
    • Finn Thain's avatar
      block/swim: Fix array bounds check · 06dc2e91
      Finn Thain authored
      commit 7ae6a2b6 upstream.
      
      In the floppy_find() function in swim.c is a call to
      get_disk(swd->unit[drive].disk). The actual parameter to this call
      can be a NULL pointer when drive == swd->floppy_count. This causes
      an oops in get_disk().
      
      Data read fault at 0x00000198 in Super Data (pc=0x1be5b6)
      BAD KERNEL BUSERR
      Oops: 00000000
      Modules linked in: swim_mod ipv6 mac8390
      PC: [<001be5b6>] get_disk+0xc/0x76
      SR: 2004  SP: 9a078bc1  a2: 0213ed90
      d0: 00000000    d1: 00000000    d2: 00000000    d3: 000000ff
      d4: 00000002    d5: 02983590    a0: 02332e00    a1: 022dfd64
      Process dd (pid: 285, task=020ab25b)
      Frame format=B ssw=074d isc=4a88 isb=6732 daddr=00000198 dobuf=00000000
      baddr=001be5bc dibuf=bfffffff ver=f
      Stack from 022dfca4:
              00000000 0203fc00 0213ed90 022dfcc0 02982936 00000000 00200000 022dfd08
              0020f85a 00200000 022dfd64 02332e00 004040fc 00000014 001be77e 022dfd64
              00334e4a 001be3f8 0800001d 022dfd64 01c04b60 01c04b70 022aba80 029828f8
              02332e00 022dfd2c 001be7ac 0203fc00 00200000 022dfd64 02103a00 01c04b60
              01c04b60 0200e400 022dfd68 000e191a 00200000 022dfd64 02103a00 0800001d
              00000000 00000003 000b89de 00500000 02103a00 01c04b60 02103a08 01c04c2e
      Call Trace: [<02982936>] floppy_find+0x3e/0x4a [swim_mod]
       [<00200000>] uart_remove_one_port+0x1a2/0x260
       [<0020f85a>] kobj_lookup+0xde/0x132
       [<00200000>] uart_remove_one_port+0x1a2/0x260
       [<001be77e>] get_gendisk+0x0/0x130
       [<00334e4a>] mutex_lock+0x0/0x2e
       [<001be3f8>] disk_block_events+0x0/0x6c
       [<029828f8>] floppy_find+0x0/0x4a [swim_mod]
       [<001be7ac>] get_gendisk+0x2e/0x130
       [<00200000>] uart_remove_one_port+0x1a2/0x260
       [<000e191a>] __blkdev_get+0x32/0x45a
       [<00200000>] uart_remove_one_port+0x1a2/0x260
       [<000b89de>] complete_walk+0x0/0x8a
       [<000e1e22>] blkdev_get+0xe0/0x29a
       [<000e1fdc>] blkdev_open+0x0/0xb0
       [<000b89de>] complete_walk+0x0/0x8a
       [<000e1fdc>] blkdev_open+0x0/0xb0
       [<000e01cc>] bd_acquire+0x74/0x8a
       [<000e205c>] blkdev_open+0x80/0xb0
       [<000e1fdc>] blkdev_open+0x0/0xb0
       [<000abf24>] do_dentry_open+0x1a4/0x322
       [<00020000>] __do_proc_douintvec+0x22/0x27e
       [<000b89de>] complete_walk+0x0/0x8a
       [<000baa62>] link_path_walk+0x0/0x48e
       [<000ba3f8>] inode_permission+0x20/0x54
       [<000ac0e4>] vfs_open+0x42/0x78
       [<000bc372>] path_openat+0x2b2/0xeaa
       [<000bc0c0>] path_openat+0x0/0xeaa
       [<0004463e>] __irq_wake_thread+0x0/0x4e
       [<0003a45a>] task_tick_fair+0x18/0xc8
       [<000bd00a>] do_filp_open+0xa0/0xea
       [<000abae0>] do_sys_open+0x11a/0x1ee
       [<00020000>] __do_proc_douintvec+0x22/0x27e
       [<000abbf4>] SyS_open+0x1e/0x22
       [<00020000>] __do_proc_douintvec+0x22/0x27e
       [<00002b40>] syscall+0x8/0xc
       [<00020000>] __do_proc_douintvec+0x22/0x27e
       [<0000c00b>] dyadic+0x1/0x28
      Code: 4e5e 4e75 4e56 fffc 2f0b 2f02 266e 0008 <206b> 0198 4a88 6732 2428 002c 661e 486b 0058 4eb9 0032 0b96 588f 4a88 672c 2008
      Disabling lock debugging due to kernel taint
      
      Fix the array index bounds check to avoid this.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: stable@vger.kernel.org # v4.14+
      Fixes: 8852ecd9 ("[PATCH] m68k: mac - Add SWIM floppy support")
      Tested-by: default avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Reviewed-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06dc2e91
    • Finn Thain's avatar
      block/swim: Select appropriate drive on device open · 8c37ac3c
      Finn Thain authored
      commit b3906535 upstream.
      
      The driver supports internal and external FDD units so the floppy_open
      function must not hard-code the drive location.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: stable@vger.kernel.org # v4.14+
      Tested-by: default avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8c37ac3c
    • Finn Thain's avatar
      block/swim: Rename macros to avoid inconsistent inverted logic · cdb0d5fa
      Finn Thain authored
      commit 56a1c5ee upstream.
      
      The Sony drive status bits use active-low logic. The swim_readbit()
      function converts that to 'C' logic for readability. Hence, the
      sense of the names of the status bit macros should not be inverted.
      
      Mostly they are correct. However, the TWOMEG_DRIVE, MFM_MODE and
      TWOMEG_MEDIA macros have inverted sense (like MkLinux). Fix this
      inconsistency and make the following patches less confusing.
      
      The same problem affects swim3.c so fix that too.
      
      No functional change.
      
      The FDHD drive status bits are documented in sonydriv.cpp from MAME
      and in swimiii.h from MkLinux.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: stable@vger.kernel.org # v4.14+
      Tested-by: default avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cdb0d5fa
    • Finn Thain's avatar
      block/swim: Remove extra put_disk() call from error path · f359e87f
      Finn Thain authored
      commit c1d6207c upstream.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: stable@vger.kernel.org # v4.14+
      Fixes: 103db8b2 ("[PATCH] swim: stop sharing request queue across multiple gendisks")
      Tested-by: default avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Reviewed-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f359e87f
    • Finn Thain's avatar
      block/swim: Don't log an error message for an invalid ioctl · b7100feb
      Finn Thain authored
      commit 8e2ab5a4 upstream.
      
      The 'eject' shell command may send various different ioctl commands.
      This leads to error messages on the console even though the FDEJECT
      ioctl succeeds.
      
      ~# eject floppy
      SWIM floppy_ioctl: unknown cmd 21257
      SWIM floppy_ioctl: unknown cmd 1
      
      Don't log an error message for an invalid ioctl, just do as the
      swim3 driver does and return -ENOTTY.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: stable@vger.kernel.org # v4.14+
      Tested-by: default avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Reviewed-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b7100feb
    • Finn Thain's avatar
      block/swim: Check drive type · 0dd9146a
      Finn Thain authored
      commit 8a500df6 upstream.
      
      The SWIM chip is compatible with GCR-mode Sony 400K/800K drives but
      this driver only supports MFM mode. Therefore only Sony FDHD drives
      are supported. Skip incompatible drives.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: stable@vger.kernel.org # v4.14+
      Tested-by: default avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0dd9146a
    • Finn Thain's avatar
      m68k/mac: Don't remap SWIM MMIO region · 43f8a4f2
      Finn Thain authored
      commit b64576cb upstream.
      
      For reasons I don't understand, calling ioremap() then iounmap() on
      the SWIM MMIO region causes a hang on 68030 (but not on 68040).
      
      ~# modprobe swim_mod
      SWIM floppy driver Version 0.2 (2008-10-30)
      SWIM device not found !
      watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [modprobe:285]
      Modules linked in: swim_mod(+)
      Format 00  Vector: 0064  PC: 000075aa  Status: 2000    Not tainted
      ORIG_D0: ffffffff  D0: d00c0000  A2: 007c2370  A1: 003f810c
      A0: 00040000  D5: d0096800  D4: d0097e00
      D3: 00000001  D2: 00000003  D1: 00000000
      Non-Maskable Interrupt
      Modules linked in: swim_mod(+)
      PC: [<000075ba>] __iounmap+0x24/0x10e
      SR: 2000  SP: 007abc48  a2: 007c2370
      d0: d00c0000    d1: 000001a0    d2: 00000019    d3: 00000001
      d4: d0097e00    d5: d0096800    a0: 00040000    a1: 003f810c
      Process modprobe (pid: 285, task=007c2370)
      Frame format=0
      Stack from 007abc7c:
              ffffffed 00000000 006a4060 004712e0 007abca0 000076ea d0080000 00080000
              010bb4b8 007abcd8 010ba542 d0096000 00000000 00000000 00000001 010bb59c
              00000000 007abf30 010bb4b8 0047760a 0047763c 00477612 00616540 007abcec
              0020a91a 00477600 0047760a 010bb4cc 007abd18 002092f2 0047760a 00333b06
              007abd5c 00000000 0047760a 010bb4cc 00404f90 004776b8 00000001 007abd38
              00209446 010bb4cc 0047760a 010bb4cc 0020938e 0031f8be 00616540 007abd64
      Call Trace: [<000076ea>] iounmap+0x46/0x5a
       [<00080000>] shrink_page_list+0x7f6/0xe06
       [<010ba542>] swim_probe+0xe4/0x496 [swim_mod]
       [<0020a91a>] platform_drv_probe+0x20/0x5e
       [<002092f2>] driver_probe_device+0x21c/0x2b8
       [<00333b06>] mutex_lock+0x0/0x2e
       [<00209446>] __driver_attach+0xb8/0xce
       [<0020938e>] __driver_attach+0x0/0xce
       [<0031f8be>] klist_next+0x0/0xa0
       [<00207562>] bus_for_each_dev+0x74/0xba
       [<000344c0>] blocking_notifier_call_chain+0x0/0x20
       [<00333b06>] mutex_lock+0x0/0x2e
       [<00208e44>] driver_attach+0x1a/0x1e
       [<0020938e>] __driver_attach+0x0/0xce
       [<00207e26>] bus_add_driver+0x188/0x234
       [<000344c0>] blocking_notifier_call_chain+0x0/0x20
       [<00209894>] driver_register+0x58/0x104
       [<000344c0>] blocking_notifier_call_chain+0x0/0x20
       [<010bd000>] swim_init+0x0/0x2c [swim_mod]
       [<0020a7be>] __platform_driver_register+0x38/0x3c
       [<010bd028>] swim_init+0x28/0x2c [swim_mod]
       [<000020dc>] do_one_initcall+0x38/0x196
       [<000344c0>] blocking_notifier_call_chain+0x0/0x20
       [<003331cc>] mutex_unlock+0x0/0x3e
       [<00333b06>] mutex_lock+0x0/0x2e
       [<003331cc>] mutex_unlock+0x0/0x3e
       [<00333b06>] mutex_lock+0x0/0x2e
       [<003331cc>] mutex_unlock+0x0/0x3e
       [<00333b06>] mutex_lock+0x0/0x2e
       [<003331cc>] mutex_unlock+0x0/0x3e
       [<00333b06>] mutex_lock+0x0/0x2e
       [<00075008>] __free_pages+0x0/0x38
       [<000045c0>] mangle_kernel_stack+0x30/0xda
       [<000344c0>] blocking_notifier_call_chain+0x0/0x20
       [<003331cc>] mutex_unlock+0x0/0x3e
       [<00333b06>] mutex_lock+0x0/0x2e
       [<0005ced4>] do_init_module+0x42/0x266
       [<010bd000>] swim_init+0x0/0x2c [swim_mod]
       [<000344c0>] blocking_notifier_call_chain+0x0/0x20
       [<0005eda0>] load_module+0x1a30/0x1e70
       [<0000465d>] mangle_kernel_stack+0xcd/0xda
       [<00331c64>] __generic_copy_from_user+0x0/0x46
       [<0033256e>] _cond_resched+0x0/0x32
       [<00331b9c>] memset+0x0/0x98
       [<0033256e>] _cond_resched+0x0/0x32
       [<0005f25c>] SyS_init_module+0x7c/0x112
       [<00002000>] _start+0x0/0x8
       [<00002000>] _start+0x0/0x8
       [<00331c82>] __generic_copy_from_user+0x1e/0x46
       [<0005f2b2>] SyS_init_module+0xd2/0x112
       [<0000465d>] mangle_kernel_stack+0xcd/0xda
       [<00002b40>] syscall+0x8/0xc
       [<0000465d>] mangle_kernel_stack+0xcd/0xda
       [<0008c00c>] pcpu_balance_workfn+0xb2/0x40e
      Code: 2200 7419 e4a9 e589 2841 d9fc 0000 1000 <2414> 7203 c282 7602 b681 6600 0096 0242 fe00 0482 0000 0000 e9c0 11c3 ed89 2642
      
      There's no need to call ioremap() for the SWIM address range, as it lies
      within the usual IO device region at 0x5000 0000, which has already been
      mapped by head.S.
      
      Remove the redundant ioremap() and iounmap() calls to fix the hang.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: stable@vger.kernel.org # v4.14+
      Tested-by: default avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43f8a4f2
    • Robert Kolchmeyer's avatar
      fsnotify: Fix fsnotify_mark_connector race · 75b98294
      Robert Kolchmeyer authored
      commit d90a10e2 upstream.
      
      fsnotify() acquires a reference to a fsnotify_mark_connector through
      the SRCU-protected pointer to_tell->i_fsnotify_marks. However, it
      appears that no precautions are taken in fsnotify_put_mark() to
      ensure that fsnotify() drops its reference to this
      fsnotify_mark_connector before assigning a value to its 'destroy_next'
      field. This can result in fsnotify_put_mark() assigning a value
      to a connector's 'destroy_next' field right before fsnotify() tries to
      traverse the linked list referenced by the connector's 'list' field.
      Since these two fields are members of the same union, this behavior
      results in a kernel panic.
      
      This issue is resolved by moving the connector's 'destroy_next' field
      into the object pointer union. This should work since the object pointer
      access is protected by both a spinlock and the value of the 'flags'
      field, and the 'flags' field is cleared while holding the spinlock in
      fsnotify_put_mark() before 'destroy_next' is updated. It shouldn't be
      possible for another thread to accidentally read from the object pointer
      after the 'destroy_next' field is updated.
      
      The offending behavior here is extremely unlikely; since
      fsnotify_put_mark() removes references to a connector (specifically,
      it ensures that the connector is unreachable from the inode it was
      formerly attached to) before updating its 'destroy_next' field, a
      sizeable chunk of code in fsnotify_put_mark() has to execute in the
      short window between when fsnotify() acquires the connector reference
      and saves the value of its 'list' field. On the HEAD kernel, I've only
      been able to reproduce this by inserting a udelay(1) in fsnotify().
      However, I've been able to reproduce this issue without inserting a
      udelay(1) anywhere on older unmodified release kernels, so I believe
      it's worth fixing at HEAD.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=199437
      Fixes: 08991e83
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarRobert Kolchmeyer <rkolchmeyer@google.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      75b98294
    • Dan Carpenter's avatar
      cdrom: information leak in cdrom_ioctl_media_changed() · 68c09d54
      Dan Carpenter authored
      commit 9de4ee40 upstream.
      
      This cast is wrong.  "cdi->capacity" is an int and "arg" is an unsigned
      long.  The way the check is written now, if one of the high 32 bits is
      set then we could read outside the info->slots[] array.
      
      This bug is pretty old and it predates git.
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      68c09d54