1. 08 May, 2017 4 commits
  2. 30 Apr, 2017 36 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.18.51 · ce88f027
      Greg Kroah-Hartman authored
      ce88f027
    • Eric Dumazet's avatar
      ping: implement proper locking · 4e340a02
      Eric Dumazet authored
      commit 43a66845 upstream.
      
      We got a report of yet another bug in ping
      
      http://www.openwall.com/lists/oss-security/2017/03/24/6
      
      ->disconnect() is not called with socket lock held.
      
      Fix this by acquiring ping rwlock earlier.
      
      Thanks to Daniel, Alexander and Andrey for letting us know this problem.
      
      Fixes: c319b4d7 ("net: ipv4: add IPPROTO_ICMP socket kind")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDaniel Jiang <danieljiang0415@gmail.com>
      Reported-by: default avatarSolar Designer <solar@openwall.com>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e340a02
    • EunTaik Lee's avatar
      staging/android/ion : fix a race condition in the ion driver · f6351425
      EunTaik Lee authored
      commit 9590232b upstream.
      
      There is a use-after-free problem in the ion driver.
      This is caused by a race condition in the ion_ioctl()
      function.
      
      A handle has ref count of 1 and two tasks on different
      cpus calls ION_IOC_FREE simultaneously.
      
      cpu 0                                   cpu 1
      -------------------------------------------------------
      ion_handle_get_by_id()
      (ref == 2)
                                  ion_handle_get_by_id()
                                  (ref == 3)
      
      ion_free()
      (ref == 2)
      
      ion_handle_put()
      (ref == 1)
      
                                  ion_free()
                                  (ref == 0 so ion_handle_destroy() is
                                  called
                                  and the handle is freed.)
      
                                  ion_handle_put() is called and it
                                  decreases the slub's next free pointer
      
      The problem is detected as an unaligned access in the
      spin lock functions since it uses load exclusive
       instruction. In some cases it corrupts the slub's
      free pointer which causes a mis-aligned access to the
      next free pointer.(kmalloc returns a pointer like
      ffffc0745b4580aa). And it causes lots of other
      hard-to-debug problems.
      
      This symptom is caused since the first member in the
      ion_handle structure is the reference count and the
      ion driver decrements the reference after it has been
      freed.
      
      To fix this problem client->lock mutex is extended
      to protect all the codes that uses the handle.
      Signed-off-by: default avatarEun Taik Lee <eun.taik.lee@samsung.com>
      Reviewed-by: default avatarLaura Abbott <labbott@redhat.com>
      Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      index 7ff2a7ec871f..33b390e7ea31
      f6351425
    • Vlad Tsyrklevich's avatar
      vfio/pci: Fix integer overflows, bitmask check · 898ef37a
      Vlad Tsyrklevich authored
      commit 05692d70 upstream.
      
      The VFIO_DEVICE_SET_IRQS ioctl did not sufficiently sanitize
      user-supplied integers, potentially allowing memory corruption. This
      patch adds appropriate integer overflow checks, checks the range bounds
      for VFIO_IRQ_SET_DATA_NONE, and also verifies that only single element
      in the VFIO_IRQ_SET_DATA_TYPE_MASK bitmask is set.
      VFIO_IRQ_SET_ACTION_TYPE_MASK is already correctly checked later in
      vfio_pci_set_irqs_ioctl().
      
      Furthermore, a kzalloc is changed to a kcalloc because the use of a
      kzalloc with an integer multiplication allowed an integer overflow
      condition to be reached without this patch. kcalloc checks for overflow
      and should prevent a similar occurrence.
      Signed-off-by: default avatarVlad Tsyrklevich <vlad@tsyrklevich.net>
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      898ef37a
    • Mauro Carvalho Chehab's avatar
      xc2028: avoid use after free · dff2b1e3
      Mauro Carvalho Chehab authored
      commit 8dfbcc43 upstream.
      
      If struct xc2028_config is passed without a firmware name,
      the following trouble may happen:
      
      [11009.907205] xc2028 5-0061: type set to XCeive xc2028/xc3028 tuner
      [11009.907491] ==================================================================
      [11009.907750] BUG: KASAN: use-after-free in strcmp+0x96/0xb0 at addr ffff8803bd78ab40
      [11009.907992] Read of size 1 by task modprobe/28992
      [11009.907994] =============================================================================
      [11009.907997] BUG kmalloc-16 (Tainted: G        W      ): kasan: bad access detected
      [11009.907999] -----------------------------------------------------------------------------
      
      [11009.908008] INFO: Allocated in xhci_urb_enqueue+0x214/0x14c0 [xhci_hcd] age=0 cpu=3 pid=28992
      [11009.908012] 	___slab_alloc+0x581/0x5b0
      [11009.908014] 	__slab_alloc+0x51/0x90
      [11009.908017] 	__kmalloc+0x27b/0x350
      [11009.908022] 	xhci_urb_enqueue+0x214/0x14c0 [xhci_hcd]
      [11009.908026] 	usb_hcd_submit_urb+0x1e8/0x1c60
      [11009.908029] 	usb_submit_urb+0xb0e/0x1200
      [11009.908032] 	usb_serial_generic_write_start+0xb6/0x4c0
      [11009.908035] 	usb_serial_generic_write+0x92/0xc0
      [11009.908039] 	usb_console_write+0x38a/0x560
      [11009.908045] 	call_console_drivers.constprop.14+0x1ee/0x2c0
      [11009.908051] 	console_unlock+0x40d/0x900
      [11009.908056] 	vprintk_emit+0x4b4/0x830
      [11009.908061] 	vprintk_default+0x1f/0x30
      [11009.908064] 	printk+0x99/0xb5
      [11009.908067] 	kasan_report_error+0x10a/0x550
      [11009.908070] 	__asan_report_load1_noabort+0x43/0x50
      [11009.908074] INFO: Freed in xc2028_set_config+0x90/0x630 [tuner_xc2028] age=1 cpu=3 pid=28992
      [11009.908077] 	__slab_free+0x2ec/0x460
      [11009.908080] 	kfree+0x266/0x280
      [11009.908083] 	xc2028_set_config+0x90/0x630 [tuner_xc2028]
      [11009.908086] 	xc2028_attach+0x310/0x8a0 [tuner_xc2028]
      [11009.908090] 	em28xx_attach_xc3028.constprop.7+0x1f9/0x30d [em28xx_dvb]
      [11009.908094] 	em28xx_dvb_init.part.3+0x8e4/0x5cf4 [em28xx_dvb]
      [11009.908098] 	em28xx_dvb_init+0x81/0x8a [em28xx_dvb]
      [11009.908101] 	em28xx_register_extension+0xd9/0x190 [em28xx]
      [11009.908105] 	em28xx_dvb_register+0x10/0x1000 [em28xx_dvb]
      [11009.908108] 	do_one_initcall+0x141/0x300
      [11009.908111] 	do_init_module+0x1d0/0x5ad
      [11009.908114] 	load_module+0x6666/0x9ba0
      [11009.908117] 	SyS_finit_module+0x108/0x130
      [11009.908120] 	entry_SYSCALL_64_fastpath+0x16/0x76
      [11009.908123] INFO: Slab 0xffffea000ef5e280 objects=25 used=25 fp=0x          (null) flags=0x2ffff8000004080
      [11009.908126] INFO: Object 0xffff8803bd78ab40 @offset=2880 fp=0x0000000000000001
      
      [11009.908130] Bytes b4 ffff8803bd78ab30: 01 00 00 00 2a 07 00 00 9d 28 00 00 01 00 00 00  ....*....(......
      [11009.908133] Object ffff8803bd78ab40: 01 00 00 00 00 00 00 00 b0 1d c3 6a 00 88 ff ff  ...........j....
      [11009.908137] CPU: 3 PID: 28992 Comm: modprobe Tainted: G    B   W       4.5.0-rc1+ #43
      [11009.908140] Hardware name:                  /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
      [11009.908142]  ffff8803bd78a000 ffff8802c273f1b8 ffffffff81932007 ffff8803c6407a80
      [11009.908148]  ffff8802c273f1e8 ffffffff81556759 ffff8803c6407a80 ffffea000ef5e280
      [11009.908153]  ffff8803bd78ab40 dffffc0000000000 ffff8802c273f210 ffffffff8155ccb4
      [11009.908158] Call Trace:
      [11009.908162]  [<ffffffff81932007>] dump_stack+0x4b/0x64
      [11009.908165]  [<ffffffff81556759>] print_trailer+0xf9/0x150
      [11009.908168]  [<ffffffff8155ccb4>] object_err+0x34/0x40
      [11009.908171]  [<ffffffff8155f260>] kasan_report_error+0x230/0x550
      [11009.908175]  [<ffffffff81237d71>] ? trace_hardirqs_off_caller+0x21/0x290
      [11009.908179]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
      [11009.908182]  [<ffffffff8155f5c3>] __asan_report_load1_noabort+0x43/0x50
      [11009.908185]  [<ffffffff8155ea00>] ? __asan_register_globals+0x50/0xa0
      [11009.908189]  [<ffffffff8194cea6>] ? strcmp+0x96/0xb0
      [11009.908192]  [<ffffffff8194cea6>] strcmp+0x96/0xb0
      [11009.908196]  [<ffffffffa13ba4ac>] xc2028_set_config+0x15c/0x630 [tuner_xc2028]
      [11009.908200]  [<ffffffffa13bac90>] xc2028_attach+0x310/0x8a0 [tuner_xc2028]
      [11009.908203]  [<ffffffff8155ea78>] ? memset+0x28/0x30
      [11009.908206]  [<ffffffffa13ba980>] ? xc2028_set_config+0x630/0x630 [tuner_xc2028]
      [11009.908211]  [<ffffffffa157a59a>] em28xx_attach_xc3028.constprop.7+0x1f9/0x30d [em28xx_dvb]
      [11009.908215]  [<ffffffffa157aa2a>] ? em28xx_dvb_init.part.3+0x37c/0x5cf4 [em28xx_dvb]
      [11009.908219]  [<ffffffffa157a3a1>] ? hauppauge_hvr930c_init+0x487/0x487 [em28xx_dvb]
      [11009.908222]  [<ffffffffa01795ac>] ? lgdt330x_attach+0x1cc/0x370 [lgdt330x]
      [11009.908226]  [<ffffffffa01793e0>] ? i2c_read_demod_bytes.isra.2+0x210/0x210 [lgdt330x]
      [11009.908230]  [<ffffffff812e87d0>] ? ref_module.part.15+0x10/0x10
      [11009.908233]  [<ffffffff812e56e0>] ? module_assert_mutex_or_preempt+0x80/0x80
      [11009.908238]  [<ffffffffa157af92>] em28xx_dvb_init.part.3+0x8e4/0x5cf4 [em28xx_dvb]
      [11009.908242]  [<ffffffffa157a6ae>] ? em28xx_attach_xc3028.constprop.7+0x30d/0x30d [em28xx_dvb]
      [11009.908245]  [<ffffffff8195222d>] ? string+0x14d/0x1f0
      [11009.908249]  [<ffffffff8195381f>] ? symbol_string+0xff/0x1a0
      [11009.908253]  [<ffffffff81953720>] ? uuid_string+0x6f0/0x6f0
      [11009.908257]  [<ffffffff811a775e>] ? __kernel_text_address+0x7e/0xa0
      [11009.908260]  [<ffffffff8104b02f>] ? print_context_stack+0x7f/0xf0
      [11009.908264]  [<ffffffff812e9846>] ? __module_address+0xb6/0x360
      [11009.908268]  [<ffffffff8137fdc9>] ? is_ftrace_trampoline+0x99/0xe0
      [11009.908271]  [<ffffffff811a775e>] ? __kernel_text_address+0x7e/0xa0
      [11009.908275]  [<ffffffff81240a70>] ? debug_check_no_locks_freed+0x290/0x290
      [11009.908278]  [<ffffffff8104a24b>] ? dump_trace+0x11b/0x300
      [11009.908282]  [<ffffffffa13e8143>] ? em28xx_register_extension+0x23/0x190 [em28xx]
      [11009.908285]  [<ffffffff81237d71>] ? trace_hardirqs_off_caller+0x21/0x290
      [11009.908289]  [<ffffffff8123ff56>] ? trace_hardirqs_on_caller+0x16/0x590
      [11009.908292]  [<ffffffff812404dd>] ? trace_hardirqs_on+0xd/0x10
      [11009.908296]  [<ffffffffa13e8143>] ? em28xx_register_extension+0x23/0x190 [em28xx]
      [11009.908299]  [<ffffffff822dcbb0>] ? mutex_trylock+0x400/0x400
      [11009.908302]  [<ffffffff810021a1>] ? do_one_initcall+0x131/0x300
      [11009.908306]  [<ffffffff81296dc7>] ? call_rcu_sched+0x17/0x20
      [11009.908309]  [<ffffffff8159e708>] ? put_object+0x48/0x70
      [11009.908314]  [<ffffffffa1579f11>] em28xx_dvb_init+0x81/0x8a [em28xx_dvb]
      [11009.908317]  [<ffffffffa13e81f9>] em28xx_register_extension+0xd9/0x190 [em28xx]
      [11009.908320]  [<ffffffffa0150000>] ? 0xffffffffa0150000
      [11009.908324]  [<ffffffffa0150010>] em28xx_dvb_register+0x10/0x1000 [em28xx_dvb]
      [11009.908327]  [<ffffffff810021b1>] do_one_initcall+0x141/0x300
      [11009.908330]  [<ffffffff81002070>] ? try_to_run_init_process+0x40/0x40
      [11009.908333]  [<ffffffff8123ff56>] ? trace_hardirqs_on_caller+0x16/0x590
      [11009.908337]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
      [11009.908340]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
      [11009.908343]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
      [11009.908346]  [<ffffffff8155ea37>] ? __asan_register_globals+0x87/0xa0
      [11009.908350]  [<ffffffff8144da7b>] do_init_module+0x1d0/0x5ad
      [11009.908353]  [<ffffffff812f2626>] load_module+0x6666/0x9ba0
      [11009.908356]  [<ffffffff812e9c90>] ? symbol_put_addr+0x50/0x50
      [11009.908361]  [<ffffffffa1580037>] ? em28xx_dvb_init.part.3+0x5989/0x5cf4 [em28xx_dvb]
      [11009.908366]  [<ffffffff812ebfc0>] ? module_frob_arch_sections+0x20/0x20
      [11009.908369]  [<ffffffff815bc940>] ? open_exec+0x50/0x50
      [11009.908374]  [<ffffffff811671bb>] ? ns_capable+0x5b/0xd0
      [11009.908377]  [<ffffffff812f5e58>] SyS_finit_module+0x108/0x130
      [11009.908379]  [<ffffffff812f5d50>] ? SyS_init_module+0x1f0/0x1f0
      [11009.908383]  [<ffffffff81004044>] ? lockdep_sys_exit_thunk+0x12/0x14
      [11009.908394]  [<ffffffff822e6936>] entry_SYSCALL_64_fastpath+0x16/0x76
      [11009.908396] Memory state around the buggy address:
      [11009.908398]  ffff8803bd78aa00: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [11009.908401]  ffff8803bd78aa80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [11009.908403] >ffff8803bd78ab00: fc fc fc fc fc fc fc fc 00 00 fc fc fc fc fc fc
      [11009.908405]                                            ^
      [11009.908407]  ffff8803bd78ab80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [11009.908409]  ffff8803bd78ac00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [11009.908411] ==================================================================
      
      In order to avoid it, let's set the cached value of the firmware
      name to NULL after freeing it. While here, return an error if
      the memory allocation fails.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dff2b1e3
    • Stefan Agner's avatar
      ARM: 8383/1: nommu: avoid deprecated source register on mov · 12ebe5ca
      Stefan Agner authored
      commit 970d96f9 upstream.
      
      In Thumb2 mode, the stack register r13 is deprecated if the
      destination register is the program counter (r15). Similar to
      head.S, head-nommu.S uses r13 to store the return address used
      after configuring the CPU's CP15 register. However, since we do
      not enable a MMU, there will be no address switch and it is
      possible to use branch with link instruction to call
      __after_proc_init.
      
      Avoid using r13 completely by using bl to call __after_proc_init
      and get rid of __secondary_switched.
      
      Beside removing unnecessary complexity, this also fixes a
      compiler warning when compiling a !MMU kernel:
      Warning: Use of r13 as a source register is deprecated when r15
      is the destination register.
      Tested-by: default avatarMaxime Coquelin <mcoquelin.stm32@gmail.com>
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      12ebe5ca
    • Arnd Bergmann's avatar
      kconfig: tinyconfig: provide whole choice blocks to avoid warnings · 39541d00
      Arnd Bergmann authored
      commit 236dec05 upstream.
      
      Using "make tinyconfig" produces a couple of annoying warnings that show
      up for build test machines all the time:
      
          .config:966:warning: override: NOHIGHMEM changes choice state
          .config:965:warning: override: SLOB changes choice state
          .config:963:warning: override: KERNEL_XZ changes choice state
          .config:962:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state
          .config:933:warning: override: SLOB changes choice state
          .config:930:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state
          .config:870:warning: override: SLOB changes choice state
          .config:868:warning: override: KERNEL_XZ changes choice state
          .config:867:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state
      
      I've made a previous attempt at fixing them and we discussed a number of
      alternatives.
      
      I tried changing the Makefile to use "merge_config.sh -n
      $(fragment-list)" but couldn't get that to work properly.
      
      This is yet another approach, based on the observation that we do want
      to see a warning for conflicting 'choice' options, and that we can
      simply make them non-conflicting by listing all other options as
      disabled.  This is a trivial patch that we can apply independent of
      plans for other changes.
      
      Link: http://lkml.kernel.org/r/20160829214952.1334674-2-arnd@arndb.de
      Link: https://storage.kernelci.org/mainline/v4.7-rc6/x86-tinyconfig/build.log
      https://patchwork.kernel.org/patch/9212749/Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarJosh Triplett <josh@joshtriplett.org>
      Reviewed-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      39541d00
    • John Crispin's avatar
      MIPS: ralink: Cosmetic change to prom_init(). · 14a1258f
      John Crispin authored
      commit 9c48568b upstream.
      
      Over the years the code has been changed various times leading to
      argc/argv being defined in a different function to where we actually
      use the variables. Clean this up by moving them to prom_init_cmdline().
      Signed-off-by: default avatarJohn Crispin <john@phrozen.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14902/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      14a1258f
    • Hannes Reinecke's avatar
      aic94xx: Skip reading user settings if flash is not found · ba57c28d
      Hannes Reinecke authored
      commit 36dd5acd upstream.
      
      If no user settings are found it's pointless trying to
      read them from flash. So skip that step.
      This also fixes a compilation warning about uninitialized variables in
      aic94xx.
      Signed-off-by: default avatarHannes Reinecke <hare@suse.de>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ba57c28d
    • Arnd Bergmann's avatar
      ARM: 8296/1: cache-l2x0: clean up aurora cache handling · 2b5f1e01
      Arnd Bergmann authored
      commit 20e783e3 upstream.
      
      The aurora cache controller is the only remaining user of a couple
      of functions in this file and are completely unused when that is
      disabled, leading to build warnings:
      
      arch/arm/mm/cache-l2x0.c:167:13: warning: 'l2x0_cache_sync' defined but not used [-Wunused-function]
      arch/arm/mm/cache-l2x0.c:184:13: warning: 'l2x0_flush_all' defined but not used [-Wunused-function]
      arch/arm/mm/cache-l2x0.c:194:13: warning: 'l2x0_disable' defined but not used [-Wunused-function]
      
      With the knowledge that the code is now aurora-specific, we can
      simplify it noticeably:
      
      - The pl310 errata workarounds are not needed on aurora and can be removed
      - As confirmed by Thomas Petazzoni from the data sheet, the cache_wait()
        macro is never needed.
      - No need to hold the lock across atomic cache sync
      - We can load the l2x0_base into a local variable across operations
      
      There should be no functional change in this patch, but readability
      and the generated object code improves, along with avoiding the
      warnings.
      
       (on Armada 370 RD and Armada XP GP, boot tested, plus a little bit of
       DMA traffic by reading data from a SD card)
      Acked-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Tested-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b5f1e01
    • Satoru Takeuchi's avatar
      btrfs: fix state->private cast on 32 bit machines · adef520a
      Satoru Takeuchi authored
      commit 6e1103a6 upstream.
      
      Suppress the following warning displayed on building 32bit (i686) kernel.
      
      ===============================================================================
      ...
         CC [M]  fs/btrfs/extent_io.o
      fs/btrfs/extent_io.c: In function ‘btrfs_free_io_failure_record’:
      fs/btrfs/extent_io.c:2193:13: warning: cast to pointer from integer of
      different size [-Wint-to-pointer-cast]
          failrec = (struct io_failure_record *)state->private;
      ...
      ===============================================================================
      Signed-off-by: default avatarSatoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
      Reported-by: default avatarChris Murphy <chris@colorremedies.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      adef520a
    • Arnd Bergmann's avatar
      gfs2: avoid uninitialized variable warning · 9d46d31e
      Arnd Bergmann authored
      commit 67893f12 upstream.
      
      We get a bogus warning about a potential uninitialized variable
      use in gfs2, because the compiler does not figure out that we
      never use the leaf number if get_leaf_nr() returns an error:
      
      fs/gfs2/dir.c: In function 'get_first_leaf':
      fs/gfs2/dir.c:802:9: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]
      fs/gfs2/dir.c: In function 'dir_split_leaf':
      fs/gfs2/dir.c:1021:8: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      Changing the 'if (!error)' to 'if (!IS_ERR_VALUE(error))' is
      sufficient to let gcc understand that this is exactly the same
      condition as in IS_ERR() so it can optimize the code path enough
      to understand it.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarBob Peterson <rpeterso@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d46d31e
    • Arnd Bergmann's avatar
      mmc: sunxi: avoid invalid pointer calculation · a73ec766
      Arnd Bergmann authored
      commit d34712d2 upstream.
      
      The sunxi mmc driver tries to calculate a dma address by using pointer
      arithmetic, which causes a warning when dma_addr_t is wider than a pointer:
      
      drivers/mmc/host/sunxi-mmc.c: In function 'sunxi_mmc_init_idma_des':
      drivers/mmc/host/sunxi-mmc.c:296:35: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
        struct sunxi_idma_des *pdes_pa = (struct sunxi_idma_des *)host->sg_dma;
                                         ^
      
      To avoid this warning and to simplify the logic, this changes
      the code to avoid the cast and calculate the correct address
      manually. The behavior should be unchanged.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarDavid Lanzendörfer <david.lanzendoerfer@o2s.ch>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a73ec766
    • Arnd Bergmann's avatar
      net: tulip: turn compile-time warning into dev_warn() · 51af0f4d
      Arnd Bergmann authored
      commit de927188 upstream.
      
      The tulip driver causes annoying build-time warnings for allmodconfig
      builds for all recent architectures:
      
      dec/tulip/winbond-840.c:910:2: warning: #warning Processor architecture undefined
      dec/tulip/tulip_core.c:101:2: warning: #warning Processor architecture undefined!
      
      This is the last remaining warning for arm64, and I'd like to get rid of
      it. We don't really know the cache line size, architecturally it would
      be at least 16 bytes, but all implementations I found have 64 or 128
      bytes. Configuring tulip for 32-byte lines as we do on ARM32 seems to
      be the safe but slow default, and nobody who cares about performance these
      days would use a tulip chip anyway, so we can just use that.
      
      To save the next person the job of trying to find out what this is for
      and picking a default for their architecture just to kill off the warning,
      I'm now removing the preprocessor #warning and turning it into a pr_warn
      or dev_warn that prints the equivalent information when the driver gets
      loaded.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarGrant Grundler <grundler@parisc-linux.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      51af0f4d
    • Sergey Ryazanov's avatar
      MIPS: MSP71xx: remove odd locking in PCI config space access code · 375f2a85
      Sergey Ryazanov authored
      commit c4a30537 upstream.
      
      Caller (generic PCI code) already do proper locking so no need to add
      another one here.
      Signed-off-by: default avatarSergey Ryazanov <ryazanov.s.a@gmail.com>
      Cc: Linux MIPS <linux-mips@linux-mips.org>
      Patchwork: https://patchwork.linux-mips.org/patch/7601/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      375f2a85
    • Arnd Bergmann's avatar
      hostap: avoid uninitialized variable use in hfa384x_get_rid · 83b7c38b
      Arnd Bergmann authored
      commit 48dc5fb3 upstream.
      
      The driver reads a value from hfa384x_from_bap(), which may fail,
      and then assigns the value to a local variable. gcc detects that
      in in the failure case, the 'rlen' variable now contains
      uninitialized data:
      
      In file included from ../drivers/net/wireless/intersil/hostap/hostap_pci.c:220:0:
      drivers/net/wireless/intersil/hostap/hostap_hw.c: In function 'hfa384x_get_rid':
      drivers/net/wireless/intersil/hostap/hostap_hw.c:842:5: warning: 'rec' may be used uninitialized in this function [-Wmaybe-uninitialized]
        if (le16_to_cpu(rec.len) == 0) {
      
      This restructures the function as suggested by Russell King, to
      make it more readable and get more reliable error handling, by
      handling each failure mode using a goto.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      83b7c38b
    • Richard Leitner's avatar
      misc: ioc4: simplify wave period measurement in clock_calibrate · b0d69335
      Richard Leitner authored
      commit 769105aa upstream.
      
      The loop for measuring the square wave periods over some cycles is
      refactored to be more easily readable. This includes avoiding a
      "by-hand-implemented" for loop with a "real" one and adding some
      comments.
      
      Furthermore the following compiler warning is avoided by this patch:
      drivers/misc/ioc4.c: In function ‘ioc4_probe’:
      drivers/misc/ioc4.c:194:16: warning: ‘start’ may be used uninitialized
      in this function [-Wmaybe-uninitialized]
        period = (end - start) /
                      ^
      drivers/misc/ioc4.c:148:11: note: ‘start’ was declared here
        uint64_t start, end, period;
                 ^
      Signed-off-by: default avatarRichard Leitner <dev@g0hl1n.net>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b0d69335
    • Arnd Bergmann's avatar
      net: vxge: avoid unused function warnings · db65717e
      Arnd Bergmann authored
      commit 57e7c8ce upstream.
      
      When CONFIG_PCI_MSI is disabled, we get warnings about unused functions
      in the vxge driver:
      
      drivers/net/ethernet/neterion/vxge/vxge-main.c:2121:13: warning: 'adaptive_coalesce_tx_interrupts' defined but not used [-Wunused-function]
      drivers/net/ethernet/neterion/vxge/vxge-main.c:2149:13: warning: 'adaptive_coalesce_rx_interrupts' defined but not used [-Wunused-function]
      
      We could add another #ifdef here, but it's nicer to avoid those warnings
      for good by converting the existing #ifdef to if(IS_ENABLED()), which has
      the same effect but provides better compile-time coverage in general,
      and lets the compiler understand better when the function is intentionally
      unused.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db65717e
    • Arnd Bergmann's avatar
      tty: nozomi: avoid a harmless gcc warning · c59bad24
      Arnd Bergmann authored
      commit a4f642a8 upstream.
      
      The nozomi wireless data driver has its own helper function to
      transfer data from a FIFO, doing an extra byte swap on big-endian
      architectures, presumably to bring the data back into byte-serial
      order after readw() or readl() perform their implicit byteswap.
      
      This helper function is used in the receive_data() function to
      first read the length into a 32-bit variable, which causes
      a compile-time warning:
      
      drivers/tty/nozomi.c: In function 'receive_data':
      drivers/tty/nozomi.c:857:9: warning: 'size' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      The problem is that gcc is unsure whether the data was actually
      read or not. We know that it is at this point, so we can replace
      it with a single readl() to shut up that warning.
      
      I am leaving the byteswap in there, to preserve the existing
      behavior, even though this seems fishy: Reading the length of
      the data into a cpu-endian variable should normally not use
      a second byteswap on big-endian systems, unless the hardware
      is aware of the CPU endianess.
      
      There appears to be a lot more confusion about endianess in this
      driver, so it probably has not worked on big-endian systems in
      a long time, if ever, and I have no way to test it. It's well
      possible that this driver has not been used by anyone in a while,
      the last patch that looks like it was tested on the hardware is
      from 2008.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c59bad24
    • Arnd Bergmann's avatar
      brcmfmac: avoid gcc-5.1 warning · b342040b
      Arnd Bergmann authored
      commit 22f44150 upstream.
      
      gcc-5.0 gained a new warning in the fwsignal portion of the brcmfmac
      driver:
      
      drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c: In function 'brcmf_fws_txs_process':
      drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      This is a false positive, and marking the brcmf_fws_hanger_poppkt function
      as 'static inline' makes the warning go away. I have checked the object
      file output and while a little code gets moved around, the size of
      the binary remains identical.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b342040b
    • Kevin Cernekee's avatar
      Fix signed/unsigned pointer warning · a3f3f11f
      Kevin Cernekee authored
      commit 97c7134a upstream.
      
      Commit 2ae83bf9 ("[CIFS] Fix setting time before epoch (negative
      time values)") changed "u64 t" to "s64 t", which makes do_div() complain
      about a pointer signedness mismatch:
      
            CC      fs/cifs/netmisc.o
          In file included from ./arch/mips/include/asm/div64.h:12:0,
                           from include/linux/kernel.h:124,
                           from include/linux/list.h:8,
                           from include/linux/wait.h:6,
                           from include/linux/net.h:23,
                           from fs/cifs/netmisc.c:25:
          fs/cifs/netmisc.c: In function ‘cifs_NTtimeToUnix’:
          include/asm-generic/div64.h:43:28: warning: comparison of distinct pointer types lacks a cast [enabled by default]
            (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
                                      ^
          fs/cifs/netmisc.c:941:22: note: in expansion of macro ‘do_div’
             ts.tv_nsec = (long)do_div(t, 10000000) * 100;
      
      Introduce a temporary "u64 abs_t" variable to fix this.
      Signed-off-by: default avatarKevin Cernekee <cernekee@gmail.com>
      Signed-off-by: default avatarSteve French <steve.french@primarydata.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a3f3f11f
    • Arnd Bergmann's avatar
      nfsd: work around a gcc-5.1 warning · a5fd3dcb
      Arnd Bergmann authored
      commit 6ac75368 upstream.
      
      gcc-5.0 warns about a potential uninitialized variable use in nfsd:
      
      fs/nfsd/nfs4state.c: In function 'nfsd4_process_open2':
      fs/nfsd/nfs4state.c:3781:3: warning: 'old_deny_bmap' may be used uninitialized in this function [-Wmaybe-uninitialized]
         reset_union_bmap_deny(old_deny_bmap, stp);
         ^
      fs/nfsd/nfs4state.c:3760:16: note: 'old_deny_bmap' was declared here
        unsigned char old_deny_bmap;
                      ^
      
      This is a false positive, the code path that is warned about cannot
      actually be reached.
      
      This adds an initialization for the variable to make the warning go
      away.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a5fd3dcb
    • Markos Chandras's avatar
      MIPS: asm: compiler: Add new macros to set ISA and arch asm annotations · 503d2d26
      Markos Chandras authored
      commit be513698 upstream.
      
      There are certain places where the code uses .set mips32 or .set mips64
      or .set arch=r4000. In preparation of MIPS R6 support, and in order to
      use as less #ifdefs as possible, we define new macros to set similar
      annotations for MIPS R6.
      Signed-off-by: default avatarMarkos Chandras <markos.chandras@imgtec.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      503d2d26
    • Paul Burton's avatar
      net: ti: cpmac: Fix compiler warning due to type confusion · aef5c5b8
      Paul Burton authored
      commit 2f5281ba upstream.
      
      cpmac_start_xmit() used the max() macro on skb->len (an unsigned int)
      and ETH_ZLEN (a signed int literal). This led to the following compiler
      warning:
      
        In file included from include/linux/list.h:8:0,
                         from include/linux/module.h:9,
                         from drivers/net/ethernet/ti/cpmac.c:19:
        drivers/net/ethernet/ti/cpmac.c: In function 'cpmac_start_xmit':
        include/linux/kernel.h:748:17: warning: comparison of distinct pointer
        types lacks a cast
          (void) (&_max1 == &_max2);  \
                         ^
        drivers/net/ethernet/ti/cpmac.c:560:8: note: in expansion of macro 'max'
          len = max(skb->len, ETH_ZLEN);
                ^
      
      On top of this, it assigned the result of the max() macro to a signed
      integer whilst all further uses of it result in it being cast to varying
      widths of unsigned integer.
      
      Fix this up by using max_t to ensure the comparison is performed as
      unsigned integers, and for consistency change the type of the len
      variable to unsigned int.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aef5c5b8
    • Oliver O'Halloran's avatar
      mm/init: fix zone boundary creation · 09f7ddc4
      Oliver O'Halloran authored
      commit 90cae1fe upstream.
      
      As a part of memory initialisation the architecture passes an array to
      free_area_init_nodes() which specifies the max PFN of each memory zone.
      This array is not necessarily monotonic (due to unused zones) so this
      array is parsed to build monotonic lists of the min and max PFN for each
      zone.  ZONE_MOVABLE is special cased here as its limits are managed by
      the mm subsystem rather than the architecture.  Unfortunately, this
      special casing is broken when ZONE_MOVABLE is the not the last zone in
      the zone list.  The core of the issue is:
      
      	if (i == ZONE_MOVABLE)
      		continue;
      	arch_zone_lowest_possible_pfn[i] =
      		arch_zone_highest_possible_pfn[i-1];
      
      As ZONE_MOVABLE is skipped the lowest_possible_pfn of the next zone will
      be set to zero.  This patch fixes this bug by adding explicitly tracking
      where the next zone should start rather than relying on the contents
      arch_zone_highest_possible_pfn[].
      
      Thie is low priority.  To get bitten by this you need to enable a zone
      that appears after ZONE_MOVABLE in the zone_type enum.  As far as I can
      tell this means running a kernel with ZONE_DEVICE or ZONE_CMA enabled,
      so I can't see this affecting too many people.
      
      I only noticed this because I've been fiddling with ZONE_DEVICE on
      powerpc and 4.6 broke my test kernel.  This bug, in conjunction with the
      changes in Taku Izumi's kernelcore=mirror patch (d91749c1) and
      powerpc being the odd architecture which initialises max_zone_pfn[] to
      ~0ul instead of 0 caused all of system memory to be placed into
      ZONE_DEVICE at boot, followed a panic since device memory cannot be used
      for kernel allocations.  I've already submitted a patch to fix the
      powerpc specific bits, but I figured this should be fixed too.
      
      Link: http://lkml.kernel.org/r/1462435033-15601-1-git-send-email-oohall@gmail.comSigned-off-by: default avatarOliver O'Halloran <oohall@gmail.com>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09f7ddc4
    • Alex Williamson's avatar
      iommu/vt-d: Remove unused variable · a7c1eda4
      Alex Williamson authored
      commit 509fca89 upstream.
      
      Unused after commit 71684406 ("iommu/vt-d: Detach domain *only*
      from attached iommus").  Reported by 0-day builder.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7c1eda4
    • Andre Przywara's avatar
      fs/nfs: fix new compiler warning about boolean in switch · 4064f65a
      Andre Przywara authored
      commit c7757074 upstream.
      
      The brand new GCC 5.1.0 warns by default on using a boolean in the
      switch condition. This results in the following warning:
      
      fs/nfs/nfs4proc.c: In function 'nfs4_proc_get_rootfh':
      fs/nfs/nfs4proc.c:3100:10: warning: switch condition has boolean value [-Wswitch-bool]
        switch (auth_probe) {
                ^
      
      This code was obviously using switch to make use of the fall-through
      semantics (without the usual comment, though).
      Rewrite that code using if statements to avoid the warning and make
      the code a bit more readable on the way.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4064f65a
    • Peter Zijlstra (Intel)'s avatar
      perf: Avoid horrible stack usage · 803e3757
      Peter Zijlstra (Intel) authored
      commit 86038c5e upstream.
      
      Both Linus (most recent) and Steve (a while ago) reported that perf
      related callbacks have massive stack bloat.
      
      The problem is that software events need a pt_regs in order to
      properly report the event location and unwind stack. And because we
      could not assume one was present we allocated one on stack and filled
      it with minimal bits required for operation.
      
      Now, pt_regs is quite large, so this is undesirable. Furthermore it
      turns out that most sites actually have a pt_regs pointer available,
      making this even more onerous, as the stack space is pointless waste.
      
      This patch addresses the problem by observing that software events
      have well defined nesting semantics, therefore we can use static
      per-cpu storage instead of on-stack.
      
      Linus made the further observation that all but the scheduler callers
      of perf_sw_event() have a pt_regs available, so we change the regular
      perf_sw_event() to require a valid pt_regs (where it used to be
      optional) and add perf_sw_event_sched() for the scheduler.
      
      We have a scheduler specific call instead of a more generic _noregs()
      like construct because we can assume non-recursion from the scheduler
      and thereby simplify the code further (_noregs would have to put the
      recursion context call inline in order to assertain which __perf_regs
      element to use).
      
      One last note on the implementation of perf_trace_buf_prepare(); we
      allow .regs = NULL for those cases where we already have a pt_regs
      pointer available and do not need another.
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Reported-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Javi Merino <javi.merino@arm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
      Cc: Vaibhav Nagarnaik <vnagarnaik@google.com>
      Link: http://lkml.kernel.org/r/20141216115041.GW3337@twins.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      803e3757
    • Alban Bedel's avatar
      MIPS: Fix the build on jz4740 after removing the custom gpio.h · 8e0aa9da
      Alban Bedel authored
      commit 5b235dc2 upstream.
      
      Somehow the wrong version of the patch to remove the use of custom
      gpio.h on mips has been merged. This patch add the missing fixes for a
      build error on jz4740 because linux/gpio.h doesn't provide any machine
      specfics definitions anymore.
      Signed-off-by: default avatarAlban Bedel <albeu@free.fr>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Brian Norris <computersforpeace@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/11089/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e0aa9da
    • Arnd Bergmann's avatar
      dm bufio: hide bogus warning · e9bf6fcf
      Arnd Bergmann authored
      mips-gcc-5.3 warns about correct code on linux-3.18 and earlier:
      
      In file included from ../include/linux/blkdev.h:4:0,
                       from ../drivers/md/dm-bufio.h:12,
                       from ../drivers/md/dm-bufio.c:9:
      ../drivers/md/dm-bufio.c: In function 'alloc_buffer':
      ../include/linux/sched.h:1975:56: warning: 'noio_flag' may be used uninitialized in this function [-Wmaybe-uninitialized]
        current->flags = (current->flags & ~PF_MEMALLOC_NOIO) | flags;
                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
      ../drivers/md/dm-bufio.c:325:11: note: 'noio_flag' was declared here
      
      The warning disappeared on later kernels with this commit: be0c37c9
      ("MIPS: Rearrange PTE bits into fixed positions.")  I assume this only
      happened because it changed some inlining decisions.
      
      On 3.18.y, we can shut up the warning by adding an extra initialization.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e9bf6fcf
    • Arnd Bergmann's avatar
      gadgetfs: fix uninitialized variable in error handling · 279b8b78
      Arnd Bergmann authored
      gcc warns about a bug in 3.18.y:
      
      drivers/usb/gadget/legacy/inode.c:648:10: warning: 'value' may be used
      
      This is caused by the backport of f01d35a1 from 4.0 to 3.18:
      c81fc59b gadgetfs: use-after-free in ->aio_read()
      
      The backported patch was buggy, but the mainline code was rewritten
      in a larger patch directly following this one in a way that fixed the
      bug.
      
      For stable, we should need only a one-line change to make sure we
      return an proper error code. It is very unlikely that anybody ever
      ran into the out-of-memory case here in practice, but the compiler
      is right in theory.
      
      Fixes: c81fc59b ("gadgetfs: use-after-free in ->aio_read()")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      279b8b78
    • Arnd Bergmann's avatar
      clk: at91: usb: fix determine_rate prototype again · f2d62e62
      Arnd Bergmann authored
      We had an incorrect backport of
      45912431 ("clk: at91: usb: propagate rate modification to the parent clk")
      that was fixed incorrectly in linux-3.18.y by
      76723e7e ("clk: at91: usb: fix determine_rate prototype")
      
      as shown by this warning:
      
      drivers/clk/at91/clk-usb.c:155:20: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
      drivers/clk/at91/clk-usb.c:193:20: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
      
      This should fix it properly.
      Acked-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2d62e62
    • Mark Rutland's avatar
      arm64: avoid returning from bad_mode · 21ffe52c
      Mark Rutland authored
      commit 7d9e8f71 upstream.
      
      Generally, taking an unexpected exception should be a fatal event, and
      bad_mode is intended to cater for this. However, it should be possible
      to contain unexpected synchronous exceptions from EL0 without bringing
      the kernel down, by sending a SIGILL to the task.
      
      We tried to apply this approach in commit 9955ac47 ("arm64:
      don't kill the kernel on a bad esr from el0"), by sending a signal for
      any bad_mode call resulting from an EL0 exception.
      
      However, this also applies to other unexpected exceptions, such as
      SError and FIQ. The entry paths for these exceptions branch to bad_mode
      without configuring the link register, and have no kernel_exit. Thus, if
      we take one of these exceptions from EL0, bad_mode will eventually
      return to the original user link register value.
      
      This patch fixes this by introducing a new bad_el0_sync handler to cater
      for the recoverable case, and restoring bad_mode to its original state,
      whereby it calls panic() and never returns. The recoverable case
      branches to bad_el0_sync with a bl, and returns to userspace via the
      usual ret_to_user mechanism.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Fixes: 9955ac47 ("arm64: don't kill the kernel on a bad esr from el0")
      Reported-by: default avatarMark Salter <msalter@redhat.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      21ffe52c
    • Suzuki K Poulose's avatar
      kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd · 2f68b351
      Suzuki K Poulose authored
      commit 8b3405e3 upstream.
      
      In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling
      unmap_stage2_range() on the entire memory range for the guest. This could
      cause problems with other callers (e.g, munmap on a memslot) trying to
      unmap a range. And since we have to unmap the entire Guest memory range
      holding a spinlock, make sure we yield the lock if necessary, after we
      unmap each PUD range.
      
      Fixes: commit d5d8184d ("KVM: ARM: Memory virtualization setup")
      Cc: Paolo Bonzini <pbonzin@redhat.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Christoffer Dall <christoffer.dall@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      [ Avoid vCPU starvation and lockup detector warnings ]
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f68b351
    • Yazen Ghannam's avatar
      x86/mce/AMD: Give a name to MCA bank 3 when accessed with legacy MSRs · 0420e558
      Yazen Ghannam authored
      commit 29f72ce3 upstream.
      
      MCA bank 3 is reserved on systems pre-Fam17h, so it didn't have a name.
      However, MCA bank 3 is defined on Fam17h systems and can be accessed
      using legacy MSRs. Without a name we get a stack trace on Fam17h systems
      when trying to register sysfs files for bank 3 on kernels that don't
      recognize Scalable MCA.
      
      Call MCA bank 3 "decode_unit" since this is what it represents on
      Fam17h. This will allow kernels without SMCA support to see this bank on
      Fam17h+ and prevent the stack trace. This will not affect older systems
      since this bank is reserved on them, i.e. it'll be ignored.
      
      Tested on AMD Fam15h and Fam17h systems.
      
        WARNING: CPU: 26 PID: 1 at lib/kobject.c:210 kobject_add_internal
        kobject: (ffff88085bb256c0): attempted to be registered with empty name!
        ...
        Call Trace:
         kobject_add_internal
         kobject_add
         kobject_create_and_add
         threshold_create_device
         threshold_init_device
      Signed-off-by: default avatarYazen Ghannam <yazen.ghannam@amd.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/1490102285-3659-1-git-send-email-Yazen.Ghannam@amd.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0420e558
    • Ravi Bangoria's avatar
      powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction · d2221b78
      Ravi Bangoria authored
      commit 9e1ba4f2 upstream.
      
      If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel
      OOPS:
      
        Bad kernel stack pointer cd93c840 at c000000000009868
        Oops: Bad kernel stack pointer, sig: 6 [#1]
        ...
        GPR00: c000001fcd93cb30 00000000cd93c840 c0000000015c5e00 00000000cd93c840
        ...
        NIP [c000000000009868] resume_kernel+0x2c/0x58
        LR [c000000000006208] program_check_common+0x108/0x180
      
      On a 64-bit system when the user probes on a 'stdu' instruction, the kernel does
      not emulate actual store in emulate_step() because it may corrupt the exception
      frame. So the kernel does the actual store operation in exception return code
      i.e. resume_kernel().
      
      resume_kernel() loads the saved stack pointer from memory using lwz, which only
      loads the low 32-bits of the address, causing the kernel crash.
      
      Fix this by loading the 64-bit value instead.
      
      Fixes: be96f633 ("powerpc: Split out instruction analysis part of emulate_step()")
      Signed-off-by: default avatarRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Reviewed-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Reviewed-by: default avatarAnanth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      [mpe: Change log massage, add stable tag]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2221b78