1. 22 Oct, 2015 40 commits
    • Uwe Kleine-König's avatar
      serial: atmel: fix error path of probe function · 14eebe6b
      Uwe Kleine-König authored
      commit 8f1bd8f2 upstream.
      
      If atmel_init_gpios fails the port has already been marked as busy (in
      line 2629), so this must be undone in the error path.
      
      This bug was introduced because I created the patch that finally
      became 722ccf41 ("serial: atmel: fix error handling when
      mctrl_gpio_init fails") on top of 3.19 which didn't have commit
      6fbb9bdf ("tty/serial: at91: fix error handling in
      atmel_serial_probe()") yet.
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Fixes: 722ccf41 ("serial: atmel: fix error handling when mctrl_gpio_init fails")
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      14eebe6b
    • Mans Rullgard's avatar
      serial: 8250: add uart_config entry for PORT_RT2880 · 9b3902ec
      Mans Rullgard authored
      commit 3c5a0357 upstream.
      
      This adds an entry to the uart_config table for PORT_RT2880
      enabling rx/tx FIFOs.  The UART is actually a Palmchip BK-3103
      which is found in several devices from Alchemy/RMI, Ralink, and
      Sigma Designs.
      Signed-off-by: default avatarMans Rullgard <mans@mansr.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b3902ec
    • Jann Horn's avatar
      drivers/tty: require read access for controlling terminal · dbec4a25
      Jann Horn authored
      commit 0c556271 upstream.
      
      This is mostly a hardening fix, given that write-only access to other
      users' ttys is usually only given through setgid tty executables.
      Signed-off-by: default avatarJann Horn <jann@thejh.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dbec4a25
    • Kosuke Tatsukawa's avatar
      tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c · 82d8846c
      Kosuke Tatsukawa authored
      commit e81107d4 upstream.
      
      My colleague ran into a program stall on a x86_64 server, where
      n_tty_read() was waiting for data even if there was data in the buffer
      in the pty.  kernel stack for the stuck process looks like below.
       #0 [ffff88303d107b58] __schedule at ffffffff815c4b20
       #1 [ffff88303d107bd0] schedule at ffffffff815c513e
       #2 [ffff88303d107bf0] schedule_timeout at ffffffff815c7818
       #3 [ffff88303d107ca0] wait_woken at ffffffff81096bd2
       #4 [ffff88303d107ce0] n_tty_read at ffffffff8136fa23
       #5 [ffff88303d107dd0] tty_read at ffffffff81368013
       #6 [ffff88303d107e20] __vfs_read at ffffffff811a3704
       #7 [ffff88303d107ec0] vfs_read at ffffffff811a3a57
       #8 [ffff88303d107f00] sys_read at ffffffff811a4306
       #9 [ffff88303d107f50] entry_SYSCALL_64_fastpath at ffffffff815c86d7
      
      There seems to be two problems causing this issue.
      
      First, in drivers/tty/n_tty.c, __receive_buf() stores the data and
      updates ldata->commit_head using smp_store_release() and then checks
      the wait queue using waitqueue_active().  However, since there is no
      memory barrier, __receive_buf() could return without calling
      wake_up_interactive_poll(), and at the same time, n_tty_read() could
      start to wait in wait_woken() as in the following chart.
      
              __receive_buf()                         n_tty_read()
      ------------------------------------------------------------------------
      if (waitqueue_active(&tty->read_wait))
      /* Memory operations issued after the
         RELEASE may be completed before the
         RELEASE operation has completed */
                                              add_wait_queue(&tty->read_wait, &wait);
                                              ...
                                              if (!input_available_p(tty, 0)) {
      smp_store_release(&ldata->commit_head,
                        ldata->read_head);
                                              ...
                                              timeout = wait_woken(&wait,
                                                TASK_INTERRUPTIBLE, timeout);
      ------------------------------------------------------------------------
      
      The second problem is that n_tty_read() also lacks a memory barrier
      call and could also cause __receive_buf() to return without calling
      wake_up_interactive_poll(), and n_tty_read() to wait in wait_woken()
      as in the chart below.
      
              __receive_buf()                         n_tty_read()
      ------------------------------------------------------------------------
                                              spin_lock_irqsave(&q->lock, flags);
                                              /* from add_wait_queue() */
                                              ...
                                              if (!input_available_p(tty, 0)) {
                                              /* Memory operations issued after the
                                                 RELEASE may be completed before the
                                                 RELEASE operation has completed */
      smp_store_release(&ldata->commit_head,
                        ldata->read_head);
      if (waitqueue_active(&tty->read_wait))
                                              __add_wait_queue(q, wait);
                                              spin_unlock_irqrestore(&q->lock,flags);
                                              /* from add_wait_queue() */
                                              ...
                                              timeout = wait_woken(&wait,
                                                TASK_INTERRUPTIBLE, timeout);
      ------------------------------------------------------------------------
      
      There are also other places in drivers/tty/n_tty.c which have similar
      calls to waitqueue_active(), so instead of adding many memory barrier
      calls, this patch simply removes the call to waitqueue_active(),
      leaving just wake_up*() behind.
      
      This fixes both problems because, even though the memory access before
      or after the spinlocks in both wake_up*() and add_wait_queue() can
      sneak into the critical section, it cannot go past it and the critical
      section assures that they will be serialized (please see "INTER-CPU
      ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a
      better explanation).  Moreover, the resulting code is much simpler.
      
      Latency measurement using a ping-pong test over a pty doesn't show any
      visible performance drop.
      Signed-off-by: default avatarKosuke Tatsukawa <tatsu@ab.jp.nec.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      82d8846c
    • covici@ccs.covici.com's avatar
      staging: speakup: fix speakup-r regression · 3581e7a9
      covici@ccs.covici.com authored
      commit b1d562ac upstream.
      
      Here is a patch to make speakup-r work again.
      
      It broke in 3.6 due to commit 4369c64c
      "Input: Send events one packet at a time)
      
      The problem was that the fakekey.c routine to fake a down arrow no
      longer functioned properly and putting the input_sync fixed it.
      
      Fixes: 4369c64cAcked-by: default avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Signed-off-by: default avatarJohn Covici <covici@ccs.covici.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3581e7a9
    • Joe Thornber's avatar
      dm cache: fix NULL pointer when switching from cleaner policy · 66deec7a
      Joe Thornber authored
      commit 2bffa150 upstream.
      
      The cleaner policy doesn't make use of the per cache block hint space in
      the metadata (unlike the other policies).  When switching from the
      cleaner policy to mq or smq a NULL pointer crash (in dm_tm_new_block)
      was observed.  The crash was caused by bugs in dm-cache-metadata.c
      when trying to skip creation of the hint btree.
      
      The minimal fix is to change hint size for the cleaner policy to 4 bytes
      (only hint size supported).
      Signed-off-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      66deec7a
    • Junichi Nomura's avatar
      dm: fix AB-BA deadlock in __dm_destroy() · 6bb03888
      Junichi Nomura authored
      commit 2a708cff upstream.
      
      __dm_destroy() takes io_barrier SRCU lock (dm_get_live_table) and
      suspend_lock in reverse order.  Doing so can cause AB-BA deadlock:
      
        __dm_destroy                    dm_swap_table
        ---------------------------------------------------
                                        mutex_lock(suspend_lock)
        dm_get_live_table()
          srcu_read_lock(io_barrier)
                                        dm_sync_table()
                                          synchronize_srcu(io_barrier)
                                            .. waiting for dm_put_live_table()
        mutex_lock(suspend_lock)
          .. waiting for suspend_lock
      
      Fix this by taking the locks in proper order.
      Signed-off-by: default avatarJun'ichi Nomura <j-nomura@ce.jp.nec.com>
      Fixes: ab7c7bb6 ("dm: hold suspend_lock while suspending device during device deletion")
      Acked-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6bb03888
    • Trond Myklebust's avatar
      namei: results of d_is_negative() should be checked after dentry revalidation · f03b7a65
      Trond Myklebust authored
      commit daf3761c upstream.
      
      Leandro Awa writes:
       "After switching to version 4.1.6, our parallelized and distributed
        workflows now fail consistently with errors of the form:
      
        T34: ./regex.c:39:22: error: config.h: No such file or directory
      
        From our 'git bisect' testing, the following commit appears to be the
        possible cause of the behavior we've been seeing: commit 766c4cbf"
      
      Al Viro says:
       "What happens is that 766c4cbf got the things subtly wrong.
      
        We used to treat d_is_negative() after lookup_fast() as "fall with
        ENOENT".  That was wrong - checking ->d_flags outside of ->d_seq
        protection is unreliable and failing with hard error on what should've
        fallen back to non-RCU pathname resolution is a bug.
      
        Unfortunately, we'd pulled the test too far up and ran afoul of
        another kind of staleness.  The dentry might have been absolutely
        stable from the RCU point of view (and we might be on UP, etc), but
        stale from the remote fs point of view.  If ->d_revalidate() returns
        "it's actually stale", dentry gets thrown away and the original code
        wouldn't even have looked at its ->d_flags.
      
        What we need is to check ->d_flags where 766c4cbf does (prior to
        ->d_seq validation) but only use the result in cases where we do not
        discard this dentry outright"
      Reported-by: default avatarLeandro Awa <lawa@nvidia.com>
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=104911
      Fixes: 766c4cbf ("namei: d_is_negative() should be checked...")
      Tested-by: default avatarLeandro Awa <lawa@nvidia.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f03b7a65
    • Bartlomiej Zolnierkiewicz's avatar
      clk: samsung: fix cpu clock's flags checking · 5003d645
      Bartlomiej Zolnierkiewicz authored
      commit 9e294bf8 upstream.
      
      CLK_CPU_HAS_DIV1 and CLK_CPU_NEEDS_DEBUG_ALT_DIV masks were
      incorrectly used as a bit numbers.  Fix it.
      
      Tested on Exynos4210 based Origen board and on Exynos5250 based
      Arndale board.
      
      Cc: Tomasz Figa <tomasz.figa@gmail.com>
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Thomas Abraham <thomas.ab@samsung.com>
      Fixes: ddeac8d9 ("clk: samsung: add infrastructure to register cpu clocks")
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Reviewed-by: default avatarJavier Martinez Canillas <javier@dowhile0.org>
      Acked-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5003d645
    • Peter Ujfalusi's avatar
      clk: ti: clk-7xx: Remove hardwired ABE clock configuration · a45c3271
      Peter Ujfalusi authored
      commit 4b3061b3 upstream.
      
      The ABE related clocks should be configured via DT and not have it wired
      inside of the kernel.
      
      Fixes: a74c52de ("clk: ti: clk-7xx: Correct ABE DPLL configuration")
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: default avatarTero Kristo <t-kristo@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a45c3271
    • Ben Dooks's avatar
      clk: ti: fix dual-registration of uart4_ick · 08f496bb
      Ben Dooks authored
      commit 19e79687 upstream.
      
      On the OMAP AM3517 platform the uart4_ick gets registered
      twice, causing any power management to /dev/ttyO3 to fail
      when trying to wake the device up.
      
      This solves the following oops:
      
      [] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09e008
      [] PC is at serial_omap_pm+0x48/0x15c
      [] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c
      
      Fixes: aafd900c ("CLK: TI: add omap3 clock init file")
      Cc: mturquette@baylibre.com
      Cc: sboyd@codeaurora.org
      Cc: linux-clk@vger.kernel.org
      Cc: linux-omap@vger.kernel.org
      Cc: linux-kernel@lists.codethink.co.uk
      Signed-off-by: default avatarBen Dooks <ben.dooks@codethink.co.uk>
      Signed-off-by: default avatarTero Kristo <t-kristo@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      08f496bb
    • Srinivas Pandruvada's avatar
      cpufreq: acpi_cpufreq: prevent crash on reading freqdomain_cpus · d1d5bed4
      Srinivas Pandruvada authored
      commit e2530367 upstream.
      
      When freqdomain_cpus attribute is read from an offlined cpu, it will
      cause crash. This change prevents calling cpufreq_show_cpus when
      policy driver_data is NULL.
      
      Crash info:
      
      [  170.814949] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
      [  170.814990] IP: [<ffffffff813b2490>] _find_next_bit.part.0+0x10/0x70
      [  170.815021] PGD 227d30067 PUD 229e56067 PMD 0
      [  170.815043] Oops: 0000 [#2] SMP
      [  170.816022] CPU: 3 PID: 3121 Comm: cat Tainted: G      D    OE   4.3.0-rc3+ #33
      ...
      ...
      [  170.816657] Call Trace:
      [  170.816672]  [<ffffffff813b2505>] ? find_next_bit+0x15/0x20
      [  170.816696]  [<ffffffff8160e47c>] cpufreq_show_cpus+0x5c/0xd0
      [  170.816722]  [<ffffffffa031a409>] show_freqdomain_cpus+0x19/0x20 [acpi_cpufreq]
      [  170.816749]  [<ffffffff8160e65b>] show+0x3b/0x60
      [  170.816769]  [<ffffffff8129b31c>] sysfs_kf_seq_show+0xbc/0x130
      [  170.816793]  [<ffffffff81299be3>] kernfs_seq_show+0x23/0x30
      [  170.816816]  [<ffffffff81240f2c>] seq_read+0xec/0x390
      [  170.816837]  [<ffffffff8129a64a>] kernfs_fop_read+0x10a/0x160
      [  170.816861]  [<ffffffff8121d9b7>] __vfs_read+0x37/0x100
      [  170.816883]  [<ffffffff813217c0>] ? security_file_permission+0xa0/0xc0
      [  170.816909]  [<ffffffff8121e2e3>] vfs_read+0x83/0x130
      [  170.816930]  [<ffffffff8121f035>] SyS_read+0x55/0xc0
      ...
      ...
      [  170.817185] ---[ end trace bc6eadf82b2b965a ]---
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1d5bed4
    • Marcin Wojtas's avatar
      mmc: sdhci-pxav3: fix error handling of armada_38x_quirks · 75c4f487
      Marcin Wojtas authored
      commit 2162d9f4 upstream.
      
      In case of armada_38x_quirks error, all clocks should be cleaned-up, same
      as after mv_conf_mbus_windows failure.
      Signed-off-by: default avatarMarcin Wojtas <mw@semihalf.com>
      Reviewed-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      75c4f487
    • Nadav Haklai's avatar
      mmc: sdhci-pxav3: disable clock inversion for HS MMC cards · 7c8e140b
      Nadav Haklai authored
      commit fa796414 upstream.
      
      According to 'FE-2946959' erratum the clock inversion option is
      needed to support slow frequencies when the card input hold time
      requirement is high. This setting is not required for high speed
      MMC and might cause timing violation.
      Signed-off-by: default avatarNadav Haklai <nadavh@marvell.com>
      Reviewed-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c8e140b
    • Nadav Haklai's avatar
      mmc: sdhci-pxav3: remove broken clock base quirk for Armada 38x sdhci driver · 273c203a
      Nadav Haklai authored
      commit 5de76bfc upstream.
      
      shci-pxav3 driver is enabling by default the
      SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN quirk. However this quirk is not
      required for Armada 38x and leads to wrong clock setting in the divider.
      Signed-off-by: default avatarNadav Haklai <nadavh@marvell.com>
      Signed-off-by: default avatarMarcin Wojtas <mw@semihalf.com>
      Reviewed-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      273c203a
    • Kinglong Mee's avatar
      nfs/filelayout: Fix NULL reference caused by double freeing of fh_array · 52402501
      Kinglong Mee authored
      commit 3ec0c979 upstream.
      
      If filelayout_decode_layout fail, _filelayout_free_lseg will causes
      a double freeing of fh_array.
      
      [ 1179.279800] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [ 1179.280198] IP: [<ffffffffa027222d>] filelayout_free_fh_array.isra.11+0x1d/0x70 [nfs_layout_nfsv41_files]
      [ 1179.281010] PGD 0
      [ 1179.281443] Oops: 0000 [#1]
      [ 1179.281831] Modules linked in: nfs_layout_nfsv41_files(OE) nfsv4(OE) nfs(OE) fscache(E) xfs libcrc32c coretemp nfsd crct10dif_pclmul ppdev crc32_pclmul crc32c_intel auth_rpcgss ghash_clmulni_intel nfs_acl lockd vmw_balloon grace sunrpc parport_pc vmw_vmci parport shpchp i2c_piix4 vmwgfx drm_kms_helper ttm drm serio_raw mptspi scsi_transport_spi mptscsih e1000 mptbase ata_generic pata_acpi [last unloaded: fscache]
      [ 1179.283891] CPU: 0 PID: 13336 Comm: cat Tainted: G           OE   4.3.0-rc1-pnfs+ #244
      [ 1179.284323] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014
      [ 1179.285206] task: ffff8800501d48c0 ti: ffff88003e3c4000 task.ti: ffff88003e3c4000
      [ 1179.285668] RIP: 0010:[<ffffffffa027222d>]  [<ffffffffa027222d>] filelayout_free_fh_array.isra.11+0x1d/0x70 [nfs_layout_nfsv41_files]
      [ 1179.286612] RSP: 0018:ffff88003e3c77f8  EFLAGS: 00010202
      [ 1179.287092] RAX: 0000000000000000 RBX: ffff88001fe78900 RCX: 0000000000000000
      [ 1179.287731] RDX: ffffea0000f40760 RSI: ffff88001fe789c8 RDI: ffff88001fe789c0
      [ 1179.288383] RBP: ffff88003e3c7810 R08: ffffea0000f40760 R09: 0000000000000000
      [ 1179.289170] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88001fe789c8
      [ 1179.289959] R13: ffff88001fe789c0 R14: ffff88004ec05a80 R15: ffff88004f935b88
      [ 1179.290791] FS:  00007f4e66bb5700(0000) GS:ffffffff81c29000(0000) knlGS:0000000000000000
      [ 1179.291580] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1179.292209] CR2: 0000000000000000 CR3: 00000000203f8000 CR4: 00000000001406f0
      [ 1179.292731] Stack:
      [ 1179.293195]  ffff88001fe78900 00000000000000d0 ffff88001fe78178 ffff88003e3c7868
      [ 1179.293676]  ffffffffa0272737 0000000000000001 0000000000000001 ffff88001fe78800
      [ 1179.294151]  00000000614fffce ffffffff81727671 ffff88001fe78100 ffff88001fe78100
      [ 1179.294623] Call Trace:
      [ 1179.295092]  [<ffffffffa0272737>] filelayout_alloc_lseg+0xa7/0x2d0 [nfs_layout_nfsv41_files]
      [ 1179.295625]  [<ffffffff81727671>] ? out_of_line_wait_on_bit+0x81/0xb0
      [ 1179.296133]  [<ffffffffa040407e>] pnfs_layout_process+0xae/0x320 [nfsv4]
      [ 1179.296632]  [<ffffffffa03e0a01>] nfs4_proc_layoutget+0x2b1/0x360 [nfsv4]
      [ 1179.297134]  [<ffffffffa0402983>] pnfs_update_layout+0x853/0xb30 [nfsv4]
      [ 1179.297632]  [<ffffffffa039db24>] ? nfs_get_lock_context+0x74/0x170 [nfs]
      [ 1179.298158]  [<ffffffffa0271807>] filelayout_pg_init_read+0x37/0x50 [nfs_layout_nfsv41_files]
      [ 1179.298834]  [<ffffffffa03a72d9>] __nfs_pageio_add_request+0x119/0x460 [nfs]
      [ 1179.299385]  [<ffffffffa03a6bd7>] ? nfs_create_request.part.9+0x37/0x2e0 [nfs]
      [ 1179.299872]  [<ffffffffa03a7cc3>] nfs_pageio_add_request+0xa3/0x1b0 [nfs]
      [ 1179.300362]  [<ffffffffa03a8635>] readpage_async_filler+0x85/0x260 [nfs]
      [ 1179.300907]  [<ffffffff81180cb1>] read_cache_pages+0x91/0xd0
      [ 1179.301391]  [<ffffffffa03a85b0>] ? nfs_read_completion+0x220/0x220 [nfs]
      [ 1179.301867]  [<ffffffffa03a8dc8>] nfs_readpages+0x128/0x200 [nfs]
      [ 1179.302330]  [<ffffffff81180ef3>] __do_page_cache_readahead+0x203/0x280
      [ 1179.302784]  [<ffffffff81180dc8>] ? __do_page_cache_readahead+0xd8/0x280
      [ 1179.303413]  [<ffffffff81181116>] ondemand_readahead+0x1a6/0x2f0
      [ 1179.303855]  [<ffffffff81181371>] page_cache_sync_readahead+0x31/0x50
      [ 1179.304286]  [<ffffffff811750a6>] generic_file_read_iter+0x4a6/0x5c0
      [ 1179.304711]  [<ffffffffa03a0316>] ? __nfs_revalidate_mapping+0x1f6/0x240 [nfs]
      [ 1179.305132]  [<ffffffffa039ccf2>] nfs_file_read+0x52/0xa0 [nfs]
      [ 1179.305540]  [<ffffffff811e343c>] __vfs_read+0xcc/0x100
      [ 1179.305936]  [<ffffffff811e3d15>] vfs_read+0x85/0x130
      [ 1179.306326]  [<ffffffff811e4a98>] SyS_read+0x58/0xd0
      [ 1179.306708]  [<ffffffff8172caaf>] entry_SYSCALL_64_fastpath+0x12/0x76
      [ 1179.307094] Code: c4 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 8b 07 49 89 f4 85 c0 74 47 48 8b 06 49 89 fd <48> 8b 38 48 85 ff 74 22 31 db eb 0c 48 63 d3 48 8b 3c d0 48 85
      [ 1179.308357] RIP  [<ffffffffa027222d>] filelayout_free_fh_array.isra.11+0x1d/0x70 [nfs_layout_nfsv41_files]
      [ 1179.309177]  RSP <ffff88003e3c77f8>
      [ 1179.309582] CR2: 0000000000000000
      Signed-off-by: default avatarKinglong Mee <kinglongmee@gmail.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Cc: William Dauchy <william@gandi.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      52402501
    • NeilBrown's avatar
      md/bitmap: don't pass -1 to bitmap_storage_alloc. · 458c21f8
      NeilBrown authored
      commit da6fb7a9 upstream.
      
      Passing -1 to bitmap_storage_alloc() causes page->index to be set to
      -1, which is quite problematic.
      
      So only pass ->cluster_slot if mddev_is_clustered().
      
      Fixes: b97e9257 ("Use separate bitmaps for each nodes in the cluster")
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      458c21f8
    • John Stultz's avatar
      clocksource: Fix abs() usage w/ 64bit values · 11195a5e
      John Stultz authored
      commit 67dfae0c upstream.
      
      This patch fixes one cases where abs() was being used with 64-bit
      nanosecond values, where the result may be capped at 32-bits.
      
      This potentially could cause watchdog false negatives on 32-bit
      systems, so this patch addresses the issue by using abs64().
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Link: http://lkml.kernel.org/r/1442279124-7309-2-git-send-email-john.stultz@linaro.orgSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      11195a5e
    • Ben Hutchings's avatar
      genirq: Fix race in register_irq_proc() · d643719c
      Ben Hutchings authored
      commit 95c2b175 upstream.
      
      Per-IRQ directories in procfs are created only when a handler is first
      added to the irqdesc, not when the irqdesc is created.  In the case of
      a shared IRQ, multiple tasks can race to create a directory.  This
      race condition seems to have been present forever, but is easier to
      hit with async probing.
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Link: http://lkml.kernel.org/r/1443266636.2004.2.camel@decadent.org.ukSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d643719c
    • Stefan Assmann's avatar
      igb: do not re-init SR-IOV during probe · 7207c3ae
      Stefan Assmann authored
      commit 6423fc34 upstream.
      
      During driver probing the following code path is triggered.
      igb_probe
      ->igb_sw_init
        ->igb_probe_vfs
          ->igb_pci_enable_sriov
            ->igb_sriov_reinit
      
      Doing the SR-IOV re-init is not necessary during probing since we're
      starting from scratch. Here we can call igb_enable_sriov() right away.
      
      Running igb_sriov_reinit() during igb_probe() also seems to cause
      occasional packet loss on some onboard 82576 NICs. Reproduced on
      Dell and HP servers with onboard 82576 NICs.
      Example:
      Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01)
      Subsystem: Dell Device [1028:0481]
      Signed-off-by: default avatarStefan Assmann <sassmann@kpanic.de>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Daniel J Blueman <daniel@numascale.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7207c3ae
    • Chas Williams's avatar
      net/xen-netfront: only napi_synchronize() if running · 75215f09
      Chas Williams authored
      commit 274b0455 upstream.
      
      If an interface isn't running napi_synchronize() will hang forever.
      
      [  392.248403] rmmod           R  running task        0   359    343 0x00000000
      [  392.257671]  ffff88003760fc88 ffff880037193b40 ffff880037193160 ffff88003760fc88
      [  392.267644]  ffff880037610000 ffff88003760fcd8 0000000100014c22 ffffffff81f75c40
      [  392.277524]  0000000000bc7010 ffff88003760fca8 ffffffff81796927 ffffffff81f75c40
      [  392.287323] Call Trace:
      [  392.291599]  [<ffffffff81796927>] schedule+0x37/0x90
      [  392.298553]  [<ffffffff8179985b>] schedule_timeout+0x14b/0x280
      [  392.306421]  [<ffffffff810f91b9>] ? irq_free_descs+0x69/0x80
      [  392.314006]  [<ffffffff811084d0>] ? internal_add_timer+0xb0/0xb0
      [  392.322125]  [<ffffffff81109d07>] msleep+0x37/0x50
      [  392.329037]  [<ffffffffa00ec79a>] xennet_disconnect_backend.isra.24+0xda/0x390 [xen_netfront]
      [  392.339658]  [<ffffffffa00ecadc>] xennet_remove+0x2c/0x80 [xen_netfront]
      [  392.348516]  [<ffffffff81481c69>] xenbus_dev_remove+0x59/0xc0
      [  392.356257]  [<ffffffff814e7217>] __device_release_driver+0x87/0x120
      [  392.364645]  [<ffffffff814e7cf8>] driver_detach+0xb8/0xc0
      [  392.371989]  [<ffffffff814e6e69>] bus_remove_driver+0x59/0xe0
      [  392.379883]  [<ffffffff814e84f0>] driver_unregister+0x30/0x70
      [  392.387495]  [<ffffffff814814b2>] xenbus_unregister_driver+0x12/0x20
      [  392.395908]  [<ffffffffa00ed89b>] netif_exit+0x10/0x775 [xen_netfront]
      [  392.404877]  [<ffffffff81124e08>] SyS_delete_module+0x1d8/0x230
      [  392.412804]  [<ffffffff8179a8ee>] system_call_fastpath+0x12/0x71
      Signed-off-by: default avatarChas Williams <3chas3@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: "Kamata, Munehisa" <kamatam@amazon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      75215f09
    • Roger Pau Monne's avatar
      xen/blkback: free requests on disconnection · a0c5f82f
      Roger Pau Monne authored
      commit f929d42c upstream.
      
      This is due to  commit 86839c56
      "xen/block: add multi-page ring support"
      
      When using an guest under UEFI - after the domain is destroyed
      the following warning comes from blkback.
      
      ------------[ cut here ]------------
      WARNING: CPU: 2 PID: 95 at
      /home/julien/works/linux/drivers/block/xen-blkback/xenbus.c:274
      xen_blkif_deferred_free+0x1f4/0x1f8()
      Modules linked in:
      CPU: 2 PID: 95 Comm: kworker/2:1 Tainted: G        W       4.2.0 #85
      Hardware name: APM X-Gene Mustang board (DT)
      Workqueue: events xen_blkif_deferred_free
      Call trace:
      [<ffff8000000890a8>] dump_backtrace+0x0/0x124
      [<ffff8000000891dc>] show_stack+0x10/0x1c
      [<ffff8000007653bc>] dump_stack+0x78/0x98
      [<ffff800000097e88>] warn_slowpath_common+0x9c/0xd4
      [<ffff800000097f80>] warn_slowpath_null+0x14/0x20
      [<ffff800000557a0c>] xen_blkif_deferred_free+0x1f0/0x1f8
      [<ffff8000000ad020>] process_one_work+0x160/0x3b4
      [<ffff8000000ad3b4>] worker_thread+0x140/0x494
      [<ffff8000000b2e34>] kthread+0xd8/0xf0
      ---[ end trace 6f859b7883c88cdd ]---
      
      Request allocation has been moved to connect_ring, which is called every
      time blkback connects to the frontend (this can happen multiple times during
      a blkback instance life cycle). On the other hand, request freeing has not
      been moved, so it's only called when destroying the backend instance. Due to
      this mismatch, blkback can allocate the request pool multiple times, without
      freeing it.
      
      In order to fix it, move the freeing of requests to xen_blkif_disconnect to
      restore the symmetry between request allocation and freeing.
      Reported-by: default avatarJulien Grall <julien.grall@citrix.com>
      Signed-off-by: default avatarRoger Pau Monné <roger.pau@citrix.com>
      Tested-by: default avatarJulien Grall <julien.grall@citrix.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: xen-devel@lists.xenproject.org
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a0c5f82f
    • Andreas Schwab's avatar
      m68k: Define asmlinkage_protect · 4f1735d1
      Andreas Schwab authored
      commit 8474ba74 upstream.
      
      Make sure the compiler does not modify arguments of syscall functions.
      This can happen if the compiler generates a tailcall to another
      function.  For example, without asmlinkage_protect sys_openat is compiled
      into this function:
      
      sys_openat:
      	clr.l %d0
      	move.w 18(%sp),%d0
      	move.l %d0,16(%sp)
      	jbra do_sys_open
      
      Note how the fourth argument is modified in place, modifying the register
      %d4 that gets restored from this stack slot when the function returns to
      user-space.  The caller may expect the register to be unmodified across
      system calls.
      Signed-off-by: default avatarAndreas Schwab <schwab@linux-m68k.org>
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f1735d1
    • Mark Salyzyn's avatar
      arm64: readahead: fault retry breaks mmap file read random detection · a1fe6749
      Mark Salyzyn authored
      commit 569ba74a upstream.
      
      This is the arm64 portion of commit 45cac65b ("readahead: fault
      retry breaks mmap file read random detection"), which was absent from
      the initial port and has since gone unnoticed. The original commit says:
      
      > .fault now can retry.  The retry can break state machine of .fault.  In
      > filemap_fault, if page is miss, ra->mmap_miss is increased.  In the second
      > try, since the page is in page cache now, ra->mmap_miss is decreased.  And
      > these are done in one fault, so we can't detect random mmap file access.
      >
      > Add a new flag to indicate .fault is tried once.  In the second try, skip
      > ra->mmap_miss decreasing.  The filemap_fault state machine is ok with it.
      
      With this change, Mark reports that:
      
      > Random read improves by 250%, sequential read improves by 40%, and
      > random write by 400% to an eMMC device with dm crypto wrapped around it.
      
      Cc: Shaohua Li <shli@kernel.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: default avatarMark Salyzyn <salyzyn@android.com>
      Signed-off-by: default avatarRiley Andrews <riandrews@android.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1fe6749
    • Li Bin's avatar
      arm64: ftrace: fix function_graph tracer panic · ec4aa911
      Li Bin authored
      commit ee556d00 upstream.
      
      When function graph tracer is enabled, the following operation
      will trigger panic:
      
      mount -t debugfs nodev /sys/kernel
      echo next_tgid > /sys/kernel/tracing/set_ftrace_filter
      echo function_graph > /sys/kernel/tracing/current_tracer
      ls /proc/
      
      ------------[ cut here ]------------
      [  198.501417] Unable to handle kernel paging request at virtual address cb88537fdc8ba316
      [  198.506126] pgd = ffffffc008f79000
      [  198.509363] [cb88537fdc8ba316] *pgd=00000000488c6003, *pud=00000000488c6003, *pmd=0000000000000000
      [  198.517726] Internal error: Oops: 94000005 [#1] SMP
      [  198.518798] Modules linked in:
      [  198.520582] CPU: 1 PID: 1388 Comm: ls Tainted: G
      [  198.521800] Hardware name: linux,dummy-virt (DT)
      [  198.522852] task: ffffffc0fa9e8000 ti: ffffffc0f9ab0000 task.ti: ffffffc0f9ab0000
      [  198.524306] PC is at next_tgid+0x30/0x100
      [  198.525205] LR is at return_to_handler+0x0/0x20
      [  198.526090] pc : [<ffffffc0002a1070>] lr : [<ffffffc0000907c0>] pstate: 60000145
      [  198.527392] sp : ffffffc0f9ab3d40
      [  198.528084] x29: ffffffc0f9ab3d40 x28: ffffffc0f9ab0000
      [  198.529406] x27: ffffffc000d6a000 x26: ffffffc000b786e8
      [  198.530659] x25: ffffffc0002a1900 x24: ffffffc0faf16c00
      [  198.531942] x23: ffffffc0f9ab3ea0 x22: 0000000000000002
      [  198.533202] x21: ffffffc000d85050 x20: 0000000000000002
      [  198.534446] x19: 0000000000000002 x18: 0000000000000000
      [  198.535719] x17: 000000000049fa08 x16: ffffffc000242efc
      [  198.537030] x15: 0000007fa472b54c x14: ffffffffff000000
      [  198.538347] x13: ffffffc0fada84a0 x12: 0000000000000001
      [  198.539634] x11: ffffffc0f9ab3d70 x10: ffffffc0f9ab3d70
      [  198.540915] x9 : ffffffc0000907c0 x8 : ffffffc0f9ab3d40
      [  198.542215] x7 : 0000002e330f08f0 x6 : 0000000000000015
      [  198.543508] x5 : 0000000000000f08 x4 : ffffffc0f9835ec0
      [  198.544792] x3 : cb88537fdc8ba316 x2 : cb88537fdc8ba306
      [  198.546108] x1 : 0000000000000002 x0 : ffffffc000d85050
      [  198.547432]
      [  198.547920] Process ls (pid: 1388, stack limit = 0xffffffc0f9ab0020)
      [  198.549170] Stack: (0xffffffc0f9ab3d40 to 0xffffffc0f9ab4000)
      [  198.582568] Call trace:
      [  198.583313] [<ffffffc0002a1070>] next_tgid+0x30/0x100
      [  198.584359] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
      [  198.585503] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
      [  198.586574] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
      [  198.587660] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
      [  198.588896] Code: aa0003f5 2a0103f4 b4000102 91004043 (885f7c60)
      [  198.591092] ---[ end trace 6a346f8f20949ac8 ]---
      
      This is because when using function graph tracer, if the traced
      function return value is in multi regs ([x0-x7]), return_to_handler
      may corrupt them. So in return_to_handler, the parameter regs should
      be protected properly.
      Signed-off-by: default avatarLi Bin <huawei.libin@huawei.com>
      Acked-by: default avatarAKASHI Takahiro <takahiro.akashi@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec4aa911
    • Ard Biesheuvel's avatar
      arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regions · 83b7575b
      Ard Biesheuvel authored
      commit 0ce3cc00 upstream.
      
      The new Properties Table feature introduced in UEFIv2.5 may
      split memory regions that cover PE/COFF memory images into
      separate code and data regions. Since these regions only differ
      in the type (runtime code vs runtime data) and the permission
      bits, but not in the memory type attributes (UC/WC/WT/WB), the
      spec does not require them to be aligned to 64 KB.
      
      Since the relative offset of PE/COFF .text and .data segments
      cannot be changed on the fly, this means that we can no longer
      pad out those regions to be mappable using 64 KB pages.
      Unfortunately, there is no annotation in the UEFI memory map
      that identifies data regions that were split off from a code
      region, so we must apply this logic to all adjacent runtime
      regions whose attributes only differ in the permission bits.
      
      So instead of rounding each memory region to 64 KB alignment at
      both ends, only round down regions that are not directly
      preceded by another runtime region with the same type
      attributes. Since the UEFI spec does not mandate that the memory
      map be sorted, this means we also need to sort it first.
      
      Note that this change will result in all EFI_MEMORY_RUNTIME
      regions whose start addresses are not aligned to the OS page
      size to be mapped with executable permissions (i.e., on kernels
      compiled with 64 KB pages). However, since these mappings are
      only active during the time that UEFI Runtime Services are being
      invoked, the window for abuse is rather small.
      Tested-by: default avatarMark Salter <msalter@redhat.com>
      Tested-by: Mark Rutland <mark.rutland@arm.com> [UEFI 2.4 only]
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Reviewed-by: default avatarMark Salter <msalter@redhat.com>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-kernel@vger.kernel.org
      Link: http://lkml.kernel.org/r/1443218539-7610-3-git-send-email-matt@codeblueprint.co.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      83b7575b
    • Eric W. Biederman's avatar
      vfs: Test for and handle paths that are unreachable from their mnt_root · 6522d3d5
      Eric W. Biederman authored
      commit 397d425d upstream.
      
      In rare cases a directory can be renamed out from under a bind mount.
      In those cases without special handling it becomes possible to walk up
      the directory tree to the root dentry of the filesystem and down
      from the root dentry to every other file or directory on the filesystem.
      
      Like division by zero .. from an unconnected path can not be given
      a useful semantic as there is no predicting at which path component
      the code will realize it is unconnected.  We certainly can not match
      the current behavior as the current behavior is a security hole.
      
      Therefore when encounting .. when following an unconnected path
      return -ENOENT.
      
      - Add a function path_connected to verify path->dentry is reachable
        from path->mnt.mnt_root.  AKA to validate that rename did not do
        something nasty to the bind mount.
      
        To avoid races path_connected must be called after following a path
        component to it's next path component.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6522d3d5
    • Eric W. Biederman's avatar
      dcache: Handle escaped paths in prepend_path · e47bf817
      Eric W. Biederman authored
      commit cde93be4 upstream.
      
      A rename can result in a dentry that by walking up d_parent
      will never reach it's mnt_root.  For lack of a better term
      I call this an escaped path.
      
      prepend_path is called by four different functions __d_path,
      d_absolute_path, d_path, and getcwd.
      
      __d_path only wants to see paths are connected to the root it passes
      in.  So __d_path needs prepend_path to return an error.
      
      d_absolute_path similarly wants to see paths that are connected to
      some root.  Escaped paths are not connected to any mnt_root so
      d_absolute_path needs prepend_path to return an error greater
      than 1.  So escaped paths will be treated like paths on lazily
      unmounted mounts.
      
      getcwd needs to prepend "(unreachable)" so getcwd also needs
      prepend_path to return an error.
      
      d_path is the interesting hold out.  d_path just wants to print
      something, and does not care about the weird cases.  Which raises
      the question what should be printed?
      
      Given that <escaped_path>/<anything> should result in -ENOENT I
      believe it is desirable for escaped paths to be printed as empty
      paths.  As there are not really any meaninful path components when
      considered from the perspective of a mount tree.
      
      So tweak prepend_path to return an empty path with an new error
      code of 3 when it encounters an escaped path.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e47bf817
    • Chaotian Jing's avatar
      mmc: core: fix dead loop of mmc_retune · a95e67a7
      Chaotian Jing authored
      commit 031277d4 upstream.
      
      When get a CRC error, start the mmc_retune, it will issue CMD19/CMD21
      to do tune, assume there were 10 clock phase need to try, phase 0 to
      phase 6 is ok, phase 7 to phase 9 is NG, we try it from 0 to 9, so
      the last CMD19/CMD21 will get CRC error, host->need_retune was set and
      cause mmc_retune was called, then dead loop of mmc_retune
      Signed-off-by: default avatarChaotian Jing <chaotian.jing@mediatek.com>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Fixes: bd11e8bd ("mmc: core: Flag re-tuning is needed on CRC errors")
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a95e67a7
    • Ulf Hansson's avatar
      mmc: core: Don't return an error for CD/WP GPIOs when GPIOLIB is unset · 31eea560
      Ulf Hansson authored
      commit 43934ece upstream.
      
      When CONFIG_GPIOLIB is unset, its stubs will return -ENOSYS. That means
      when the mmc core parses DT for CD/WP GPIOs via mmc_of_parse(), -ENOSYS
      becomes propagated to the caller. Typically this means that the mmc host
      driver fails to probe.
      
      As the CD/WP GPIOs are already treated as optional, let's extend that to
      cover the case when CONFIG_GPIOLIB is unset.
      Reported-by: default avatarMichal Simek <michal.simek@xilinx.com>
      Fixes: 16b23787 ("mmc: sdhci-of-arasan: Call OF parsing for MMC")
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarMichal Simek <michal.simek@xilinx.com>
      Acked-by: default avatarVenu Byravarasu <vbyravarasu@nvidia.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      31eea560
    • Nicholas Bellinger's avatar
      iscsi-target: Avoid OFMarker + IFMarker negotiation · 145ba598
      Nicholas Bellinger authored
      commit 673681ca upstream.
      
      This patch fixes a v4.2+ regression introduced by commit c04a6091
      that removed support for obsolete sync-and-steering markers usage
      as originally defined in RFC-3720.
      
      The regression would involve attempting to send OFMarker=No +
      IFMarker=No keys during opertional negotiation login phase,
      including when initiators did not actually propose these keys.
      
      The result for MSFT iSCSI initiators would be random junk in
      TCP stream after the last successful login request was been sent
      signaling the move to full feature phase (FFP) operation.
      
      To address this bug, go ahead and avoid negotiating these keys
      by default unless the initiator explicitly proposes them, but
      still respond to them with 'No' if they are proposed.
      Reported-by: default avatarDragan Milivojević <galileo@pkm-inc.com>
      Bisected-by: default avatarChristophe Vu-Brugier <cvubrugier@fastmail.fm>
      Tested-by: default avatarChristophe Vu-Brugier <cvubrugier@fastmail.fm>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Cc: Andy Grover <agrover@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      145ba598
    • Sudip Mukherjee's avatar
      net: via/Kconfig: GENERIC_PCI_IOMAP required if PCI not selected · a885e8bb
      Sudip Mukherjee authored
      commit 21343ac2 upstream.
      
      The builds of allmodconfig of avr32 is failing with:
      
      drivers/net/ethernet/via/via-rhine.c:1098:2: error: implicit declaration
      of function 'pci_iomap' [-Werror=implicit-function-declaration]
      drivers/net/ethernet/via/via-rhine.c:1119:2: error: implicit declaration
      of function 'pci_iounmap' [-Werror=implicit-function-declaration]
      
      The generic empty pci_iomap and pci_iounmap is used only if CONFIG_PCI
      is not defined and CONFIG_GENERIC_PCI_IOMAP is defined.
      
      Add GENERIC_PCI_IOMAP in the dependency list for VIA_RHINE as we are
      getting build failure when CONFIG_PCI and CONFIG_GENERIC_PCI_IOMAP both
      are not defined.
      Signed-off-by: default avatarSudip Mukherjee <sudip@vectorindia.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a885e8bb
    • shengyong's avatar
      UBI: return ENOSPC if no enough space available · 40396228
      shengyong authored
      commit 7c7feb2e upstream.
      
      UBI: attaching mtd1 to ubi0
      UBI: scanning is finished
      UBI error: init_volumes: not enough PEBs, required 706, available 686
      UBI error: ubi_wl_init: no enough physical eraseblocks (-20, need 1)
      UBI error: ubi_attach_mtd_dev: failed to attach mtd1, error -12 <= NOT ENOMEM
      UBI error: ubi_init: cannot attach mtd1
      
      If available PEBs are not enough when initializing volumes, return -ENOSPC
      directly. If available PEBs are not enough when initializing WL, return
      -ENOSPC instead of -ENOMEM.
      Signed-off-by: default avatarSheng Yong <shengyong1@huawei.com>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Reviewed-by: default avatarDavid Gstir <david@sigma-star.at>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      40396228
    • Richard Weinberger's avatar
      UBI: Validate data_size · fc433796
      Richard Weinberger authored
      commit 281fda27 upstream.
      
      Make sure that data_size is less than LEB size.
      Otherwise a handcrafted UBI image is able to trigger
      an out of bounds memory access in ubi_compare_lebs().
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Reviewed-by: default avatarDavid Gstir <david@sigma-star.at>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fc433796
    • Richard Weinberger's avatar
      UBIFS: Kill unneeded locking in ubifs_init_security · b8e759b6
      Richard Weinberger authored
      commit cf6f54e3 upstream.
      
      Fixes the following lockdep splat:
      [    1.244527] =============================================
      [    1.245193] [ INFO: possible recursive locking detected ]
      [    1.245193] 4.2.0-rc1+ #37 Not tainted
      [    1.245193] ---------------------------------------------
      [    1.245193] cp/742 is trying to acquire lock:
      [    1.245193]  (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff812b3f69>] ubifs_init_security+0x29/0xb0
      [    1.245193]
      [    1.245193] but task is already holding lock:
      [    1.245193]  (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff81198e7f>] path_openat+0x3af/0x1280
      [    1.245193]
      [    1.245193] other info that might help us debug this:
      [    1.245193]  Possible unsafe locking scenario:
      [    1.245193]
      [    1.245193]        CPU0
      [    1.245193]        ----
      [    1.245193]   lock(&sb->s_type->i_mutex_key#9);
      [    1.245193]   lock(&sb->s_type->i_mutex_key#9);
      [    1.245193]
      [    1.245193]  *** DEADLOCK ***
      [    1.245193]
      [    1.245193]  May be due to missing lock nesting notation
      [    1.245193]
      [    1.245193] 2 locks held by cp/742:
      [    1.245193]  #0:  (sb_writers#5){.+.+.+}, at: [<ffffffff811ad37f>] mnt_want_write+0x1f/0x50
      [    1.245193]  #1:  (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff81198e7f>] path_openat+0x3af/0x1280
      [    1.245193]
      [    1.245193] stack backtrace:
      [    1.245193] CPU: 2 PID: 742 Comm: cp Not tainted 4.2.0-rc1+ #37
      [    1.245193] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140816_022509-build35 04/01/2014
      [    1.245193]  ffffffff8252d530 ffff88007b023a38 ffffffff814f6f49 ffffffff810b56c5
      [    1.245193]  ffff88007c30cc80 ffff88007b023af8 ffffffff810a150d ffff88007b023a68
      [    1.245193]  000000008101302a ffff880000000000 00000008f447e23f ffffffff8252d500
      [    1.245193] Call Trace:
      [    1.245193]  [<ffffffff814f6f49>] dump_stack+0x4c/0x65
      [    1.245193]  [<ffffffff810b56c5>] ? console_unlock+0x1c5/0x510
      [    1.245193]  [<ffffffff810a150d>] __lock_acquire+0x1a6d/0x1ea0
      [    1.245193]  [<ffffffff8109fa78>] ? __lock_is_held+0x58/0x80
      [    1.245193]  [<ffffffff810a1a93>] lock_acquire+0xd3/0x270
      [    1.245193]  [<ffffffff812b3f69>] ? ubifs_init_security+0x29/0xb0
      [    1.245193]  [<ffffffff814fc83b>] mutex_lock_nested+0x6b/0x3a0
      [    1.245193]  [<ffffffff812b3f69>] ? ubifs_init_security+0x29/0xb0
      [    1.245193]  [<ffffffff812b3f69>] ? ubifs_init_security+0x29/0xb0
      [    1.245193]  [<ffffffff812b3f69>] ubifs_init_security+0x29/0xb0
      [    1.245193]  [<ffffffff8128e286>] ubifs_create+0xa6/0x1f0
      [    1.245193]  [<ffffffff81198e7f>] ? path_openat+0x3af/0x1280
      [    1.245193]  [<ffffffff81195d15>] vfs_create+0x95/0xc0
      [    1.245193]  [<ffffffff8119929c>] path_openat+0x7cc/0x1280
      [    1.245193]  [<ffffffff8109ffe3>] ? __lock_acquire+0x543/0x1ea0
      [    1.245193]  [<ffffffff81088f20>] ? sched_clock_cpu+0x90/0xc0
      [    1.245193]  [<ffffffff81088c00>] ? calc_global_load_tick+0x60/0x90
      [    1.245193]  [<ffffffff81088f20>] ? sched_clock_cpu+0x90/0xc0
      [    1.245193]  [<ffffffff811a9cef>] ? __alloc_fd+0xaf/0x180
      [    1.245193]  [<ffffffff8119ac55>] do_filp_open+0x75/0xd0
      [    1.245193]  [<ffffffff814ffd86>] ? _raw_spin_unlock+0x26/0x40
      [    1.245193]  [<ffffffff811a9cef>] ? __alloc_fd+0xaf/0x180
      [    1.245193]  [<ffffffff81189bd9>] do_sys_open+0x129/0x200
      [    1.245193]  [<ffffffff81189cc9>] SyS_open+0x19/0x20
      [    1.245193]  [<ffffffff81500717>] entry_SYSCALL_64_fastpath+0x12/0x6f
      
      While the lockdep splat is a false positive, becuase path_openat holds i_mutex
      of the parent directory and ubifs_init_security() tries to acquire i_mutex
      of a new inode, it reveals that taking i_mutex in ubifs_init_security() is
      in vain because it is only being called in the inode allocation path
      and therefore nobody else can see the inode yet.
      Reported-and-tested-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Reviewed-and-tested-by: default avatarDongsheng Yang <yangds.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: dedekind1@gmail.com
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8e759b6
    • Christian Engelmayer's avatar
      rsi: Fix possible leak when loading firmware · f7e8cdc5
      Christian Engelmayer authored
      commit a8b97745 upstream.
      
      Commit 5d5cd85f ("rsi: Fix failure to load firmware after memory
      leak fix and fix the leak") also added a check on the allocation of
      DMA-accessible memory that may directly return. In that case the
      already allocated firmware data is leaked. Make sure the data is
      always freed correctly. Detected by Coverity CID 1316519.
      
      Fixes: 5d5cd85f ("rsi: Fix failure to load firmware after memory leak fix and fix the leak")
      Signed-off-by: default avatarChristian Engelmayer <cengelma@gmx.at>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f7e8cdc5
    • Paul Mackerras's avatar
      powerpc/MSI: Fix race condition in tearing down MSI interrupts · f4cbe79f
      Paul Mackerras authored
      commit e297c939 upstream.
      
      This fixes a race which can result in the same virtual IRQ number
      being assigned to two different MSI interrupts.  The most visible
      consequence of that is usually a warning and stack trace from the
      sysfs code about an attempt to create a duplicate entry in sysfs.
      
      The race happens when one CPU (say CPU 0) is disposing of an MSI
      while another CPU (say CPU 1) is setting up an MSI.  CPU 0 calls
      (for example) pnv_teardown_msi_irqs(), which calls
      msi_bitmap_free_hwirqs() to indicate that the MSI (i.e. its
      hardware IRQ number) is no longer in use.  Then, before CPU 0 gets
      to calling irq_dispose_mapping() to free up the virtal IRQ number,
      CPU 1 comes in and calls msi_bitmap_alloc_hwirqs() to allocate an
      MSI, and gets the same hardware IRQ number that CPU 0 just freed.
      CPU 1 then calls irq_create_mapping() to get a virtual IRQ number,
      which sees that there is currently a mapping for that hardware IRQ
      number and returns the corresponding virtual IRQ number (which is
      the same virtual IRQ number that CPU 0 was using).  CPU 0 then
      calls irq_dispose_mapping() and frees that virtual IRQ number.
      Now, if another CPU comes along and calls irq_create_mapping(), it
      is likely to get the virtual IRQ number that was just freed,
      resulting in the same virtual IRQ number apparently being used for
      two different hardware interrupts.
      
      To fix this race, we just move the call to msi_bitmap_free_hwirqs()
      to after the call to irq_dispose_mapping().  Since virq_to_hw()
      doesn't work for the virtual IRQ number after irq_dispose_mapping()
      has been called, we need to call it before irq_dispose_mapping() and
      remember the result for the msi_bitmap_free_hwirqs() call.
      
      The pattern of calling msi_bitmap_free_hwirqs() before
      irq_dispose_mapping() appears in 5 places under arch/powerpc, and
      appears to have originated in commit 05af7bd2 ("[POWERPC] MPIC
      U3/U4 MSI backend") from 2007.
      
      Fixes: 05af7bd2 ("[POWERPC] MPIC U3/U4 MSI backend")
      Reported-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      f4cbe79f
    • Kapileshwar Singh's avatar
      tools lib traceevent: Fix string handling in heterogeneous arch environments · 607877ba
      Kapileshwar Singh authored
      commit c2e4b24f upstream.
      
      When a trace recorded on a 32-bit device is processed with a 64-bit
      binary, the higher 32-bits of the address need to ignored.
      
      The lack of this results in the output of the 64-bit pointer
      value to the trace as the 32-bit address lookup fails in find_printk().
      
      Before:
      
        burn-1778  [003]   548.600305: bputs:   0xc0046db2s: 2cec5c058d98c
      
      After:
      
        burn-1778  [003]   548.600305: bputs:   0xc0046db2s: RT throttling activated
      
      The problem occurs in PRINT_FIELD when the field is recognized as a
      pointer to a string (of the type const char *)
      
      Heterogeneous architectures cases below can arise and should be handled:
      
      * Traces recorded using 32-bit addresses processed on a 64-bit machine
      * Traces recorded using 64-bit addresses processed on a 32-bit machine
      Reported-by: default avatarJuri Lelli <juri.lelli@arm.com>
      Signed-off-by: default avatarKapileshwar Singh <kapileshwar.singh@arm.com>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Javi Merino <javi.merino@arm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/r/1442928123-13824-1-git-send-email-kapileshwar.singh@arm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      607877ba
    • Linus Lüssing's avatar
      batman-adv: Fix potentially broken skb network header access · c79c3ece
      Linus Lüssing authored
      commit 53cf037b upstream.
      
      The two commits noted below added calls to ip_hdr() and ipv6_hdr(). They
      need a correctly set skb network header.
      
      Unfortunately we cannot rely on the device drivers to set it for us.
      Therefore setting it in the beginning of the according ndo_start_xmit
      handler.
      
      Fixes: 1d8ab8d3 ("batman-adv: Modified forwarding behaviour for multicast packets")
      Fixes: ab49886e ("batman-adv: Add IPv4 link-local/IPv6-ll-all-nodes multicast support")
      Signed-off-by: default avatarLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: default avatarMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: default avatarAntonio Quartulli <antonio@meshcoding.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c79c3ece
    • Linus Lüssing's avatar
      batman-adv: Fix potential synchronization issues in mcast tvlv handler · 897b938a
      Linus Lüssing authored
      commit 8a4023c5 upstream.
      
      So far the mcast tvlv handler did not anticipate the processing of
      multiple incoming OGMs from the same originator at the same time. This
      can lead to various issues:
      
      * Broken refcounting: For instance two mcast handlers might both assume
        that an originator just got multicast capabilities and will together
        wrongly decrease mcast.num_disabled by two, potentially leading to
        an integer underflow.
      
      * Potential kernel panic on hlist_del_rcu(): Two mcast handlers might
        one after another try to do an
        hlist_del_rcu(&orig->mcast_want_all_*_node). The second one will
        cause memory corruption / crashes.
        (Reported by: Sven Eckelmann <sven@narfation.org>)
      
      Right in the beginning the code path makes assumptions about the current
      multicast related state of an originator and bases all updates on that. The
      easiest and least error prune way to fix the issues in this case is to
      serialize multiple mcast handler invocations with a spinlock.
      
      Fixes: 60432d75 ("batman-adv: Announce new capability via multicast TVLV")
      Signed-off-by: default avatarLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: default avatarMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: default avatarAntonio Quartulli <antonio@meshcoding.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      897b938a