1. 10 Aug, 2015 32 commits
    • Alexey Brodkin's avatar
      ARC: make sure instruction_pointer() returns unsigned value · c7bc7995
      Alexey Brodkin authored
      commit f51e2f19 upstream.
      
      Currently instruction_pointer() returns pt_regs->ret and so return value
      is of type "long", which implicitly stands for "signed long".
      
      While that's perfectly fine when dealing with 32-bit values if return
      value of instruction_pointer() gets assigned to 64-bit variable sign
      extension may happen.
      
      And at least in one real use-case it happens already.
      In perf_prepare_sample() return value of perf_instruction_pointer()
      (which is an alias to instruction_pointer() in case of ARC) is assigned
      to (struct perf_sample_data)->ip (which type is "u64").
      
      And what we see if instuction pointer points to user-space application
      that in case of ARC lays below 0x8000_0000 "ip" gets set properly with
      leading 32 zeros. But if instruction pointer points to kernel address
      space that starts from 0x8000_0000 then "ip" is set with 32 leadig
      "f"-s. I.e. id instruction_pointer() returns 0x8100_0000, "ip" will be
      assigned with 0xffff_ffff__8100_0000. Which is obviously wrong.
      
      In particular that issuse broke output of perf, because perf was unable
      to associate addresses like 0xffff_ffff__8100_0000 with anything from
      /proc/kallsyms.
      
      That's what we used to see:
       ----------->8----------
        6.27%  ls       [unknown]                [k] 0xffffffff8046c5cc
        2.96%  ls       libuClibc-0.9.34-git.so  [.] memcpy
        2.25%  ls       libuClibc-0.9.34-git.so  [.] memset
        1.66%  ls       [unknown]                [k] 0xffffffff80666536
        1.54%  ls       libuClibc-0.9.34-git.so  [.] 0x000224d6
        1.18%  ls       libuClibc-0.9.34-git.so  [.] 0x00022472
       ----------->8----------
      
      With that change perf output looks much better now:
       ----------->8----------
        8.21%  ls       [kernel.kallsyms]        [k] memset
        3.52%  ls       libuClibc-0.9.34-git.so  [.] memcpy
        2.11%  ls       libuClibc-0.9.34-git.so  [.] malloc
        1.88%  ls       libuClibc-0.9.34-git.so  [.] memset
        1.64%  ls       [kernel.kallsyms]        [k] _raw_spin_unlock_irqrestore
        1.41%  ls       [kernel.kallsyms]        [k] __d_lookup_rcu
       ----------->8----------
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Cc: arc-linux-dev@synopsys.com
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c7bc7995
    • Sergei Shtylyov's avatar
      can: rcar_can: fix IRQ check · dfe8266d
      Sergei Shtylyov authored
      commit 5e63e6ba upstream.
      
      rcar_can_probe() regards 0 as a wrong IRQ #, despite platform_get_irq() that it
      calls returns negative error code in that case. This leads to the following
      being printed to the console when attempting to open the device:
      
      error requesting interrupt fffffffa
      
      because  rcar_can_open() calls request_irq() with a negative IRQ #, and that
      function naturally fails with -EINVAL.
      
      Check for the negative error codes instead and propagate them upstream instead
      of just returning -ENODEV.
      
      Fixes: fd115931 ("can: add Renesas R-Car CAN driver")
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      dfe8266d
    • Filipe Manana's avatar
      Btrfs: fix list transaction->pending_ordered corruption · 16da885e
      Filipe Manana authored
      commit d3efe084 upstream.
      
      When we call btrfs_commit_transaction(), we splice the list "ordered"
      of our transaction handle into the transaction's "pending_ordered"
      list, but we don't re-initialize the "ordered" list of our transaction
      handle, this means it still points to the same elements it used to
      before the splice. Then we check if the current transaction's state is
      >= TRANS_STATE_COMMIT_START and if it is we end up calling
      btrfs_end_transaction() which simply splices again the "ordered" list
      of our handle into the transaction's "pending_ordered" list, leaving
      multiple pointers to the same ordered extents which results in list
      corruption when we are iterating, removing and freeing ordered extents
      at btrfs_wait_pending_ordered(), resulting in access to dangling
      pointers / use-after-free issues.
      Similarly, btrfs_end_transaction() can end up in some cases calling
      btrfs_commit_transaction(), and both did a list splice of the transaction
      handle's "ordered" list into the transaction's "pending_ordered" without
      re-initializing the handle's "ordered" list, resulting in exactly the
      same problem.
      
      This produces the following warning on a kernel with linked list
      debugging enabled:
      
      [109749.265416] ------------[ cut here ]------------
      [109749.266410] WARNING: CPU: 7 PID: 324 at lib/list_debug.c:59 __list_del_entry+0x5a/0x98()
      [109749.267969] list_del corruption. prev->next should be ffff8800ba087e20, but was fffffff8c1f7c35d
      (...)
      [109749.287505] Call Trace:
      [109749.288135]  [<ffffffff8145f077>] dump_stack+0x4f/0x7b
      [109749.298080]  [<ffffffff81095de5>] ? console_unlock+0x356/0x3a2
      [109749.331605]  [<ffffffff8104b3b0>] warn_slowpath_common+0xa1/0xbb
      [109749.334849]  [<ffffffff81260642>] ? __list_del_entry+0x5a/0x98
      [109749.337093]  [<ffffffff8104b410>] warn_slowpath_fmt+0x46/0x48
      [109749.337847]  [<ffffffff81260642>] __list_del_entry+0x5a/0x98
      [109749.338678]  [<ffffffffa053e8bf>] btrfs_wait_pending_ordered+0x46/0xdb [btrfs]
      [109749.340145]  [<ffffffffa058a65f>] ? __btrfs_run_delayed_items+0x149/0x163 [btrfs]
      [109749.348313]  [<ffffffffa054077d>] btrfs_commit_transaction+0x36b/0xa10 [btrfs]
      [109749.349745]  [<ffffffff81087310>] ? trace_hardirqs_on+0xd/0xf
      [109749.350819]  [<ffffffffa055370d>] btrfs_sync_file+0x36f/0x3fc [btrfs]
      [109749.351976]  [<ffffffff8118ec98>] vfs_fsync_range+0x8f/0x9e
      [109749.360341]  [<ffffffff8118ecc3>] vfs_fsync+0x1c/0x1e
      [109749.368828]  [<ffffffff8118ee1d>] do_fsync+0x34/0x4e
      [109749.369790]  [<ffffffff8118f045>] SyS_fsync+0x10/0x14
      [109749.370925]  [<ffffffff81465197>] system_call_fastpath+0x12/0x6f
      [109749.382274] ---[ end trace 48e0d07f7c03d95a ]---
      
      On a non-debug kernel this leads to invalid memory accesses, causing a
      crash. Fix this by using list_splice_init() instead of list_splice() in
      btrfs_commit_transaction() and btrfs_end_transaction().
      
      Fixes: 50d9aa99 ("Btrfs: make sure logged extents complete in the current transaction V3"
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      16da885e
    • Filipe Manana's avatar
      Btrfs: fix memory leak in the extent_same ioctl · b5ada126
      Filipe Manana authored
      commit 497b4050 upstream.
      
      We were allocating memory with memdup_user() but we were never releasing
      that memory. This affected pretty much every call to the ioctl, whether
      it deduplicated extents or not.
      
      This issue was reported on IRC by Julian Taylor and on the mailing list
      by Marcel Ritter, credit goes to them for finding the issue.
      Reported-by: default avatarJulian Taylor <jtaylor.debian@googlemail.com>
      Reported-by: default avatarMarcel Ritter <ritter.marcel@gmail.com>
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarMark Fasheh <mfasheh@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b5ada126
    • Johannes Thumshirn's avatar
      USB: serial: Destroy serial_minors IDR on module exit · 063fd5d5
      Johannes Thumshirn authored
      commit d23f47d4 upstream.
      
      Destroy serial_minors IDR on module exit, reclaiming the allocated memory.
      
      This was detected by the following semantic patch (written by Luis
      Rodriguez <mcgrof@suse.com>)
      
      <SmPL>
      @ defines_module_init @
      declarer name module_init, module_exit;
      declarer name DEFINE_IDR;
      identifier init;
      @@
      
      module_init(init);
      
      @ defines_module_exit @
      identifier exit;
      @@
      
      module_exit(exit);
      
      @ declares_idr depends on defines_module_init && defines_module_exit @
      identifier idr;
      @@
      
      DEFINE_IDR(idr);
      
      @ on_exit_calls_destroy depends on declares_idr && defines_module_exit @
      identifier declares_idr.idr, defines_module_exit.exit;
      @@
      
      exit(void)
      {
       ...
       idr_destroy(&idr);
       ...
      }
      
      @ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @
      identifier declares_idr.idr, defines_module_exit.exit;
      @@
      
      exit(void)
      {
       ...
       +idr_destroy(&idr);
      }
      </SmPL>
      Signed-off-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      063fd5d5
    • Mugunthan V N's avatar
      drivers: net: cpsw: fix crash while accessing second slave ethernet interface · d5ecf017
      Mugunthan V N authored
      commit 1973db0d upstream.
      
      When cpsw's number of slave is set to 1 in device tree and while
      accessing second slave ndev and priv in cpsw_tx_interrupt(),
      there is a kernel crash. This is due to cpsw_get_slave_priv()
      not verifying number of slaves while retriving netdev priv and
      returns a invalid memory region. Fixing the issue by introducing
      number of slave check in cpsw_get_slave_priv() and
      cpsw_get_slave_ndev().
      
      [   15.879589] Unable to handle kernel paging request at virtual address 0f0e142c
      [   15.888540] pgd = ed374000
      [   15.891359] [0f0e142c] *pgd=00000000
      [   15.895105] Internal error: Oops: 5 [#1] SMP ARM
      [   15.899936] Modules linked in:
      [   15.903139] CPU: 0 PID: 593 Comm: udhcpc Tainted: G        W       4.1.0-12205-gfda8b18c-dirty #10
      [   15.912386] Hardware name: Generic AM43 (Flattened Device Tree)
      [   15.918557] task: ed2a2e00 ti: ed3fe000 task.ti: ed3fe000
      [   15.924187] PC is at cpsw_tx_interrupt+0x30/0x44
      [   15.929008] LR is at _raw_spin_unlock_irqrestore+0x40/0x44
      [   15.934726] pc : [<c048b9cc>]    lr : [<c05ef4f4>]    psr: 20000193
      [   15.934726] sp : ed3ffc08  ip : ed2a2e40  fp : 00000000
      [   15.946685] r10: c0969ce8  r9 : c0969cfc  r8 : 00000000
      [   15.952129] r7 : 000000c6  r6 : ee54ab00  r5 : ee169c64  r4 : ee534e00
      [   15.958932] r3 : 0f0e0d0c  r2 : 00000000  r1 : ed3ffbc0  r0 : 00000001
      [   15.965735] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
      [   15.973261] Control: 10c5387d  Table: ad374059  DAC: 00000015
      [   15.979246] Process udhcpc (pid: 593, stack limit = 0xed3fe218)
      [   15.985414] Stack: (0xed3ffc08 to 0xed400000)
      [   15.989954] fc00:                   ee54ab00 c009928c c0a9e648 60000193 000032e4 ee169c00
      [   15.998478] fc20: ee169c64 ee169c00 ee169c64 ee54ab00 00000001 00000001 ee67e268 ee008800
      [   16.006995] fc40: ee534800 c009946c ee169c00 ee169c64 c08bd660 c009c370 c009c2a4 000000c6
      [   16.015513] fc60: c08b75c4 c08b0854 00000000 c0098b3c 000000c6 c0098c50 ed3ffcb0 0000003a
      [   16.024033] fc80: ed3ffcb0 fa24010c c08b7800 fa240100 ee7e9880 c00094c4 c05ef4e8 60000013
      [   16.032556] fca0: ffffffff ed3ffce4 ee7e9880 c05ef964 00000001 ed2a33d8 00000000 ed2a2e00
      [   16.041080] fcc0: 60000013 ee536bf8 60000013 ee51b800 ee7e9880 ee67e268 ee7e9880 ee534800
      [   16.049603] fce0: c0ad0768 ed3ffcf8 c008e910 c05ef4e8 60000013 ffffffff 00000001 00000001
      [   16.058121] fd00: ee536bf8 c0487a04 00000000 00000000 ee534800 00000000 00000156 c048c990
      [   16.066645] fd20: 00000000 00000000 c0969f40 00000000 00000000 c05000e8 00000001 00000000
      [   16.075167] fd40: 00000000 c051eefc 00000000 ee67e268 00000000 00000000 ee51b800 ed3ffd9c
      [   16.083690] fd60: 00000000 ee67e200 ee51b800 ee7e9880 ee67e268 00000000 00000000 ee67e200
      [   16.092211] fd80: ee51b800 ee7e9880 ee67e268 ee534800 ee67e200 c051eedc ee67e268 00000010
      [   16.100727] fda0: 00000000 00000000 ee7e9880 ee534800 00000000 ee67e268 ee51b800 c05006fc
      [   16.109247] fdc0: ee67e268 00000001 c0500488 00000156 ee7e9880 00000000 ed3fe000 fffffff4
      [   16.117771] fde0: ed3fff1c ee7e9880 ee534800 00000148 00000000 ed1f8340 00000000 00000000
      [   16.126289] fe00: 00000000 c05a9054 00000000 00000000 00000156 c0ab62a8 00000010 ed3e7000
      [   16.134812] fe20: 00000000 00000008 edcfb700 ed3fff1c c0fb5f94 ed2a2e00 c0fb5f64 000005d8
      [   16.143336] fe40: c0a9b3b8 00000000 ed3e7070 00000000 00000000 00000000 00009f40 00000000
      [   16.151858] fe60: 00000000 00020022 00110008 00000000 00000000 43004400 00000000 ffffffff
      [   16.160374] fe80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [   16.168898] fea0: edcfb700 bee5f380 00000014 00000000 ed3fe000 00000000 00004400 c04e2b64
      [   16.177415] fec0: 00000002 c04e3b00 ed3ffeec 00000001 0000011a 00000000 00000000 bee5f394
      [   16.185937] fee0: 00000148 ed3fff10 00000014 00000001 00000000 00000000 ed3ffee4 00000000
      [   16.194459] ff00: 00000000 00000000 00000000 c04e3664 00080011 00000002 06000000 ffffffff
      [   16.202980] ff20: 0000ffff ffffffff 0000ffff c008dd54 ee5a6f08 ee636e80 c096972d c0089c14
      [   16.211499] ff40: 00000000 60000013 ee5a6f40 60000013 00000000 ee5a6f40 00000002 00000006
      [   16.220023] ff60: 00000000 edcfb700 00000001 ed2a2e00 c000f60c 00000001 0000011a c008ea34
      [   16.228540] ff80: 00000006 00000000 bee5f380 00000014 bee5f380 00000014 bee5f380 00000122
      [   16.237059] ffa0: c000f7c4 c000f5e0 bee5f380 00000014 00000006 bee5f394 00000148 00000000
      [   16.245581] ffc0: bee5f380 00000014 bee5f380 00000122 fffffd6e 00004300 00004800 00004400
      [   16.254104] ffe0: bee5f378 bee5f36c 000307ec b6f39044 40000010 00000006 ed36fa40 00000000
      [   16.262642] [<c048b9cc>] (cpsw_tx_interrupt) from [<c009928c>] (handle_irq_event_percpu+0x64/0x204)
      [   16.272076] [<c009928c>] (handle_irq_event_percpu) from [<c009946c>] (handle_irq_event+0x40/0x64)
      [   16.281330] [<c009946c>] (handle_irq_event) from [<c009c370>] (handle_fasteoi_irq+0xcc/0x1a8)
      [   16.290220] [<c009c370>] (handle_fasteoi_irq) from [<c0098b3c>] (generic_handle_irq+0x20/0x30)
      [   16.299197] [<c0098b3c>] (generic_handle_irq) from [<c0098c50>] (__handle_domain_irq+0x64/0xdc)
      [   16.308273] [<c0098c50>] (__handle_domain_irq) from [<c00094c4>] (gic_handle_irq+0x20/0x60)
      [   16.316987] [<c00094c4>] (gic_handle_irq) from [<c05ef964>] (__irq_svc+0x44/0x5c)
      [   16.324779] Exception stack(0xed3ffcb0 to 0xed3ffcf8)
      [   16.330044] fca0:                                     00000001 ed2a33d8 00000000 ed2a2e00
      [   16.338567] fcc0: 60000013 ee536bf8 60000013 ee51b800 ee7e9880 ee67e268 ee7e9880 ee534800
      [   16.347090] fce0: c0ad0768 ed3ffcf8 c008e910 c05ef4e8 60000013 ffffffff
      [   16.353987] [<c05ef964>] (__irq_svc) from [<c05ef4e8>] (_raw_spin_unlock_irqrestore+0x34/0x44)
      [   16.362973] [<c05ef4e8>] (_raw_spin_unlock_irqrestore) from [<c0487a04>] (cpdma_check_free_tx_desc+0x60/0x6c)
      [   16.373311] [<c0487a04>] (cpdma_check_free_tx_desc) from [<c048c990>] (cpsw_ndo_start_xmit+0xb4/0x1ac)
      [   16.383017] [<c048c990>] (cpsw_ndo_start_xmit) from [<c05000e8>] (dev_hard_start_xmit+0x2a4/0x4c0)
      [   16.392364] [<c05000e8>] (dev_hard_start_xmit) from [<c051eedc>] (sch_direct_xmit+0xf4/0x210)
      [   16.401246] [<c051eedc>] (sch_direct_xmit) from [<c05006fc>] (__dev_queue_xmit+0x2ac/0x7bc)
      [   16.409960] [<c05006fc>] (__dev_queue_xmit) from [<c05a9054>] (packet_sendmsg+0xc68/0xeb4)
      [   16.418585] [<c05a9054>] (packet_sendmsg) from [<c04e2b64>] (sock_sendmsg+0x14/0x24)
      [   16.426663] [<c04e2b64>] (sock_sendmsg) from [<c04e3b00>] (SyS_sendto+0xb4/0xe0)
      [   16.434377] [<c04e3b00>] (SyS_sendto) from [<c000f5e0>] (ret_fast_syscall+0x0/0x54)
      [   16.442360] Code: e5943118 e593303c e3530000 0a000002 (e5930720)
      [   16.448716] ---[ end trace a68159f094d85ba6 ]---
      [   16.453526] Kernel panic - not syncing: Fatal exception in interrupt
      [   16.460149] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
      Signed-off-by: default avatarMugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d5ecf017
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Have branch tracer use recursive field of task struct · 1f827fd5
      Steven Rostedt (Red Hat) authored
      commit 6224beb1 upstream.
      
      Fengguang Wu's tests triggered a bug in the branch tracer's start up
      test when CONFIG_DEBUG_PREEMPT set. This was because that config
      adds some debug logic in the per cpu field, which calls back into
      the branch tracer.
      
      The branch tracer has its own recursive checks, but uses a per cpu
      variable to implement it. If retrieving the per cpu variable calls
      back into the branch tracer, you can see how things will break.
      
      Instead of using a per cpu variable, use the trace_recursion field
      of the current task struct. Simply set a bit when entering the
      branch tracing and clear it when leaving. If the bit is set on
      entry, just don't do the tracing.
      
      There's also the case with lockdep, as the local_irq_save() called
      before the recursion can also trigger code that can call back into
      the function. Changing that to a raw_local_irq_save() will protect
      that as well.
      
      This prevents the recursion and the inevitable crash that follows.
      
      Link: http://lkml.kernel.org/r/20150630141803.GA28071@wfg-t540p.sh.intel.comReported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Tested-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1f827fd5
    • Stefan Wahren's avatar
      ARM: dts: mx23: fix iio-hwmon support · d2e50432
      Stefan Wahren authored
      commit e8e94ed6 upstream.
      
      In order to get iio-hwmon support, the lradc must be declared as an
      iio provider. So fix this issue by adding the #io-channel-cells property.
      Signed-off-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Fixes: bd798f9c ("ARM: dts: mxs: Add iio-hwmon to mx23 soc")
      Reviewed-by: default avatarMarek Vasut <marex@denx.de>
      Reviewed-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d2e50432
    • Mike Snitzer's avatar
      bio integrity: do not assume bio_integrity_pool exists if bioset exists · 050b6b27
      Mike Snitzer authored
      commit bb8bd38b upstream.
      
      bio_integrity_alloc() and bio_integrity_free() assume that if a bio was
      allocated from a bioset that that bioset also had its bio_integrity_pool
      allocated using bioset_integrity_create().  This is a very bad
      assumption given that bioset_create() and bioset_integrity_create() are
      completely disjoint.  Not all callers of bioset_create() have been
      trained to also call bioset_integrity_create() -- and they may not care
      to be.
      
      Fix this by falling back to kmalloc'ing 'struct bio_integrity_payload'
      rather than force all bioset consumers to (wastefully) preallocate a
      bio_integrity_pool that they very likely won't actually need (given the
      niche nature of the current block integrity support).
      
      Otherwise, a NULL pointer "Kernel BUG" with a trace like the following
      will be observed (as seen on s390x using zfcp storage) because dm-io
      doesn't use bioset_integrity_create() when creating its bioset:
      
          [  791.643338] Call Trace:
          [  791.643339] ([<00000003df98b848>] 0x3df98b848)
          [  791.643341]  [<00000000002c5de8>] bio_integrity_alloc+0x48/0xf8
          [  791.643348]  [<00000000002c6486>] bio_integrity_prep+0xae/0x2f0
          [  791.643349]  [<0000000000371e38>] blk_queue_bio+0x1c8/0x3d8
          [  791.643355]  [<000000000036f8d0>] generic_make_request+0xc0/0x100
          [  791.643357]  [<000000000036f9b2>] submit_bio+0xa2/0x198
          [  791.643406]  [<000003ff801f9774>] dispatch_io+0x15c/0x3b0 [dm_mod]
          [  791.643419]  [<000003ff801f9b3e>] dm_io+0x176/0x2f0 [dm_mod]
          [  791.643423]  [<000003ff8074b28a>] do_reads+0x13a/0x1a8 [dm_mirror]
          [  791.643425]  [<000003ff8074b43a>] do_mirror+0x142/0x298 [dm_mirror]
          [  791.643428]  [<0000000000154fca>] process_one_work+0x18a/0x3f8
          [  791.643432]  [<000000000015598a>] worker_thread+0x132/0x3b0
          [  791.643435]  [<000000000015d49a>] kthread+0xd2/0xd8
          [  791.643438]  [<00000000005bc0ca>] kernel_thread_starter+0x6/0xc
          [  791.643446]  [<00000000005bc0c4>] kernel_thread_starter+0x0/0xc
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      050b6b27
    • Zhao Junwang's avatar
      drm: add a check for x/y in drm_mode_setcrtc · 83034100
      Zhao Junwang authored
      commit 01447e9f upstream.
      
      legacy setcrtc ioctl does take a 32 bit value which might indeed
      overflow
      
      the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't
      needed any more with this
      
      v2: -polish the annotation according to Daniel's comment
      
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarZhao Junwang <zhjwpku@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      83034100
    • Michal Nazarewicz's avatar
      usb: f_mass_storage: limit number of reported LUNs · be30468a
      Michal Nazarewicz authored
      commit 8515bac0 upstream.
      
      Mass storage function created via configfs always reports eight LUNs
      to the hosts even if only one LUN has been configured.  Adjust the
      number when the USB function is allocated based on LUNs that user
      has created.
      Tested-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      [ luis: backported to 3.16:
        - file rename: drivers/usb/gadget/function/f_mass_storage.c ->
          drivers/usb/gadget/f_mass_storage.c ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      be30468a
    • Felipe Balbi's avatar
      usb: musb: host: rely on port_mode to call musb_start() · 6645294d
      Felipe Balbi authored
      commit be9d3988 upstream.
      
      Currently, we're calling musb_start() twice for DRD ports
      in some situations. This has been observed to cause enumeration
      issues after suspend/resume cycles with AM335x.
      
      In order to fix the problem, we just have to fix the check
      on musb_has_gadget() so that it only returns true if
      current mode is Host and ignore the fact that we have or
      not a gadget driver loaded.
      
      Fixes: ae44df2e (usb: musb: call musb_start() only once in OTG mode)
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Tested-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6645294d
    • Joe Thornber's avatar
      dm btree: silence lockdep lock inversion in dm_btree_del() · 75064b47
      Joe Thornber authored
      commit 1c751879 upstream.
      
      Allocate memory using GFP_NOIO when deleting a btree.  dm_btree_del()
      can be called via an ioctl and we don't want to recurse into the FS or
      block layer.
      Signed-off-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      75064b47
    • Peter Sanford's avatar
      USB: cp210x: add ID for Aruba Networks controllers · 7ec0d6ed
      Peter Sanford authored
      commit f98a7aa8 upstream.
      
      Add the USB serial console device ID for Aruba Networks 7xxx series
      controllers which have a USB port for their serial console.
      Signed-off-by: default avatarPeter Sanford <peter@sanford.io>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7ec0d6ed
    • Claudio Cappelli's avatar
      USB: option: add 2020:4000 ID · c4ec7b0e
      Claudio Cappelli authored
      commit f6d7fb37 upstream.
      
      Add device Olivetti Olicard 300 (Network Connect: MT6225) - IDs 2020:4000.
      
      T:  Bus=01 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=2020 ProdID=4000 Rev=03.00
      S:  Manufacturer=Network Connect
      S:  Product=MT6225
      C:  #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
      Signed-off-by: default avatarClaudio Cappelli <claudio.cappelli.linux@gmail.com>
      Suggested-by: default avatarLars Melin <larsm17@gmail.com>
      [johan: amend commit message with devices info ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c4ec7b0e
    • Vutla, Lokesh's avatar
      crypto: omap-des - Fix unmapping of dma channels · a87b9ace
      Vutla, Lokesh authored
      commit acb33cc5 upstream.
      
      dma_unmap_sg() is being called twice after completing the
      task. Looks like this is a copy paste error when creating
      des driver.
      With this the following warn appears during boot:
      
      [    4.210457] ------------[ cut here ]------------
      [    4.215114] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1080 check_unmap+0x710/0x9a0()
      [    4.222899] omap-des 480a5000.des: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x00000000ab2ce000] [size=8 bytes]
      [    4.236785] Modules linked in:
      [    4.239860] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.39-02999-g1bc045a-dirty #182
      [    4.247918] [<c001678c>] (unwind_backtrace) from [<c0012574>] (show_stack+0x10/0x14)
      [    4.255710] [<c0012574>] (show_stack) from [<c05a37e8>] (dump_stack+0x84/0xb8)
      [    4.262977] [<c05a37e8>] (dump_stack) from [<c0046464>] (warn_slowpath_common+0x68/0x8c)
      [    4.271107] [<c0046464>] (warn_slowpath_common) from [<c004651c>] (warn_slowpath_fmt+0x30/0x40)
      [    4.279854] [<c004651c>] (warn_slowpath_fmt) from [<c02d50a4>] (check_unmap+0x710/0x9a0)
      [    4.287991] [<c02d50a4>] (check_unmap) from [<c02d5478>] (debug_dma_unmap_sg+0x90/0x19c)
      [    4.296128] [<c02d5478>] (debug_dma_unmap_sg) from [<c04a77d8>] (omap_des_done_task+0x1cc/0x3e4)
      [    4.304963] [<c04a77d8>] (omap_des_done_task) from [<c004a090>] (tasklet_action+0x84/0x124)
      [    4.313370] [<c004a090>] (tasklet_action) from [<c004a4ac>] (__do_softirq+0xf0/0x20c)
      [    4.321235] [<c004a4ac>] (__do_softirq) from [<c004a840>] (irq_exit+0x98/0xec)
      [    4.328500] [<c004a840>] (irq_exit) from [<c000f9ac>] (handle_IRQ+0x50/0xb0)
      [    4.335589] [<c000f9ac>] (handle_IRQ) from [<c0008688>] (gic_handle_irq+0x28/0x5c)
      
      Removing the duplicate call to dma_unmap_sg().
      Reported-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a87b9ace
    • Vineet Gupta's avatar
      ARC: Override toplevel default -O2 with -O3 · 42dd36b8
      Vineet Gupta authored
      commit 97709069 upstream.
      
      ARC kernels have historically been built with -O3, despite top level
      Makefile defaulting to -O2. This was facilitated by implicitly ordering
      of arch makefile include AFTER top level assigned -O2.
      
      An upstream fix to top level a1c48bb1 ("Makefile: Fix unrecognized
      cross-compiler command line options") changed the ordering, making ARC
      -O3 defunct.
      
      Fix that by NOT relying on any ordering whatsoever and use the proper
      arch override facility now present in kbuild (ARCH_*FLAGS)
      
      Depends-on: ("kbuild: Allow arch Makefiles to override {cpp,ld,c}flags")
      Suggested-by: default avatarMichal Marek <mmarek@suse.cz>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      42dd36b8
    • Michal Marek's avatar
      kbuild: Allow arch Makefiles to override {cpp,ld,c}flags · 4a9e44d5
      Michal Marek authored
      commit 61754c18 upstream.
      
      Since commit a1c48bb1 (Makefile: Fix unrecognized cross-compiler command
      line options), the arch Makefile is included earlier by the main
      Makefile, preventing the arc architecture to set its -O3 compiler
      option. Since there might be more use cases for an arch Makefile to
      fine-tune the options, add support for ARCH_CPPFLAGS, ARCH_AFLAGS and
      ARCH_CFLAGS variables that are appended to the respective kbuild
      variables. The user still has the final say via the KCPPFLAGS, KAFLAGS
      and KCFLAGS variables.
      Reported-by: default avatarVineet Gupta <Vineet.Gupta1@synopsys.com>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4a9e44d5
    • Dennis Yang's avatar
      dm btree remove: fix bug in redistribute3 · 88913562
      Dennis Yang authored
      commit 4c7e3093 upstream.
      
      redistribute3() shares entries out across 3 nodes.  Some entries were
      being moved the wrong way, breaking the ordering.  This manifested as a
      BUG() in dm-btree-remove.c:shift() when entries were removed from the
      btree.
      
      For additional context see:
      https://www.redhat.com/archives/dm-devel/2015-May/msg00113.htmlSigned-off-by: default avatarDennis Yang <shinrairis@gmail.com>
      Signed-off-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      88913562
    • Peter Meerwald's avatar
      iio: tmp006: Check channel info on write · 4e882ddc
      Peter Meerwald authored
      commit 8d05abfa upstream.
      
      only SAMP_FREQ is writable
      
      Will lead to SAMP_FREQ being written by any attempt to write
      to the other exported attributes and hence a rather unexpected
      result!
      Signed-off-by: default avatarPeter Meerwald <pmeerw@pmeerw.net>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4e882ddc
    • Dominic Sacré's avatar
      ALSA: usb-audio: Add MIDI support for Steinberg MI2/MI4 · 2b24558c
      Dominic Sacré authored
      commit 0689a86a upstream.
      
      The Steinberg MI2 and MI4 interfaces are compatible with the USB class
      audio spec, but the MIDI part of the devices is reported as a vendor
      specific interface.
      
      This patch adds entries to quirks-table.h to recognize the MIDI
      endpoints. Audio functionality was already working and is unaffected by
      this change.
      Signed-off-by: default avatarDominic Sacré <dominic.sacre@gmx.de>
      Signed-off-by: default avatarAlbert Huitsing <albert@huitsing.nl>
      Acked-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2b24558c
    • Jan Leupold's avatar
      iio: adc: at91_adc: allow to use full range of startup time · 46fa3216
      Jan Leupold authored
      commit 2ab5f39b upstream.
      
      The DT-Property "atmel,adc-startup-time" is stored in an u8 for a microsecond
      value. When trying to increase the value of STARTUP in Register AT91_ADC_MR
      some higher values can't be reached.
      
      Change the type in function parameter and private structure field from u8 to
      u32.
      Signed-off-by: default avatarJan Leupold <leupold@rsi-elektrotechnik.de>
      [nicolas.ferre@atmel.com: change commit message, increase u16 to u32 for startup time]
      Signed-off-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Acked-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      46fa3216
    • JM Friedt's avatar
      iio: DAC: ad5624r_spi: fix bit shift of output data value · 76fa7f7a
      JM Friedt authored
      commit adfa9698 upstream.
      
      The value sent on the SPI bus is shifted by an erroneous number of bits.
      The shift value was already computed in the iio_chan_spec structure and
      hence subtracting this argument to 16 yields an erroneous data position
      in the SPI stream.
      Signed-off-by: default avatarJM Friedt <jmfriedt@femto-st.fr>
      Acked-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      76fa7f7a
    • Adriana Reus's avatar
      iio: inv-mpu: Specify the expected format/precision for write channels · a86dcecb
      Adriana Reus authored
      commit 6a3c45bb upstream.
      
      The gyroscope needs IIO_VAL_INT_PLUS_NANO for the scale channel and
      unless specified write returns MICRO by default.
      This needs to be properly specified so that write operations into scale
      have the expected behaviour.
      Signed-off-by: default avatarAdriana Reus <adriana.reus@intel.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a86dcecb
    • Fabio Estevam's avatar
      iio: twl4030-madc: Pass the IRQF_ONESHOT flag · 6f344cab
      Fabio Estevam authored
      commit 6c0d48cb upstream.
      
      Since commit 1c6c6952 ("genirq: Reject bogus threaded irq requests")
      threaded IRQs without a primary handler need to be requested with
      IRQF_ONESHOT, otherwise the request will fail.
      
      So pass the IRQF_ONESHOT flag in this case.
      
      The semantic patch that makes this change is available
      in scripts/coccinelle/misc/irqf_oneshot.cocci.
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6f344cab
    • Ezequiel Garcia's avatar
      spi: pl022: Specify 'num-cs' property as required in devicetree binding · 18e63e7e
      Ezequiel Garcia authored
      commit ea6055c4 upstream.
      
      Since commit 39a6ac11 ("spi/pl022: Devicetree support w/o platform data")
      the 'num-cs' parameter cannot be passed through platform data when probing
      with devicetree. Instead, it's a required devicetree property.
      
      Fix the binding documentation so the property is properly specified.
      
      Fixes: 39a6ac11 ("spi/pl022: Devicetree support w/o platform data")
      Signed-off-by: default avatarEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      18e63e7e
    • Lukasz Majewski's avatar
      thermal: step_wise: fix: Prevent from binary overflow when trend is dropping · 072cb4b1
      Lukasz Majewski authored
      commit 26bb0e9a upstream.
      
      It turns out that some boards can have instance->lower greater than 0 and
      when thermal trend is dropping it results with next_target equal to -1.
      
      Since the next_target is defined as unsigned long it is interpreted as
      0xFFFFFFFF and larger than instance->upper.
      As a result the next_target is set to instance->upper which ramps up to
      maximal cooling device target when the temperature is steadily decreasing.
      Signed-off-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
      Cc: Mason <slash.tmp@free.fr>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      072cb4b1
    • Markos Chandras's avatar
      MIPS: kernel: traps: Fix broken indentation · df008cc8
      Markos Chandras authored
      commit 761b4493 upstream.
      
      Fix broken indentation caused by the SMTC removal
      commit b633648c
      ("MIPS: MT: Remove SMTC support")
      Signed-off-by: default avatarMarkos Chandras <markos.chandras@imgtec.com>
      Fixes: b633648c ("MIPS: MT: Remove SMTC support")
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/10581/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      df008cc8
    • Al Viro's avatar
      33d24096
    • Joe Perches's avatar
      hpfs: hpfs_error: Remove static buffer, use vsprintf extension %pV instead · f4937fc7
      Joe Perches authored
      commit a28e4b2b upstream.
      
      Removing unnecessary static buffers is good.
      Use the vsprintf %pV extension instead.
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarMikulas Patocka <mikulas@twibright.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f4937fc7
    • Sanidhya Kashyap's avatar
      hpfs: kstrdup() out of memory handling · 5bbb9aca
      Sanidhya Kashyap authored
      commit ce657611 upstream.
      
      There is a possibility of nothing being allocated to the new_opts in
      case of memory pressure, therefore return ENOMEM for such case.
      Signed-off-by: default avatarSanidhya Kashyap <sanidhya.gatech@gmail.com>
      Signed-off-by: default avatarMikulas Patocka <mikulas@twibright.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5bbb9aca
    • Grigori Goronzy's avatar
      drm/radeon: unpin cursor BOs on suspend and pin them again on resume (v2) · dc5203b2
      Grigori Goronzy authored
      commit f3cbb17b upstream.
      
      Everything is evicted from VRAM before suspend, so we need to make
      sure all BOs are unpinned and re-pinned after resume. Fixes broken
      mouse cursor after resume introduced by commit b9729b17.
      
      [Michel Dänzer: Add pinning BOs on resume]
      
      v2:
      [Alex Deucher: merge cursor unpin into fb unpin loop]
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100541
      Reviewed-by: Christian König <christian.koenig@amd.com> (v1)
      Signed-off-by: default avatarGrigori Goronzy <greg@chown.ath.cx>
      Signed-off-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      dc5203b2
  2. 20 Jul, 2015 8 commits
    • Mario Kleiner's avatar
      drm/radeon: Handle irqs only based on irq ring, not irq status regs. · df93d3fe
      Mario Kleiner authored
      commit 07f18f0b upstream.
      
      Trying to resolve issues with missed vblanks and impossible
      values inside delivered kms pageflip completion events showed
      that radeon's irq handling sometimes doesn't handle valid irqs,
      but silently skips them. This was observed for vblank interrupts.
      
      Although those irqs have corresponding events queued in the gpu's
      irq ring at time of interrupt, and therefore the corresponding
      handling code gets triggered by these events, the handling code
      sometimes silently skipped processing the irq. The reason for those
      skips is that the handling code double-checks for each irq event if
      the corresponding irq status bits in the irq status registers
      are set. Sometimes those bits are not set at time of check
      for valid irqs, maybe due to some hardware race on some setups?
      
      The problem only seems to happen on some machine + card combos
      sometimes, e.g., never happened during my testing of different PC
      cards of the DCE-2/3/4 generation a year ago, but happens consistently
      now on two different Apple Mac cards (RV730, DCE-3, Apple iMac and
      Evergreen JUNIPER, DCE-4 in a Apple MacPro). It also doesn't happen
      at each interrupt but only occassionally every couple of
      hundred or thousand vblank interrupts.
      
      This results in XOrg warning messages like
      
      "[  7084.472] (WW) RADEON(0): radeon_dri2_flip_event_handler:
      Pageflip completion event has impossible msc 420120 < target_msc 420121"
      
      as well as skipped frames and problems for applications that
      use kms pageflip events or vblank events, e.g., users of DRI2 and
      DRI3/Present, Waylands Weston compositor, etc. See also
      
      https://bugs.freedesktop.org/show_bug.cgi?id=85203
      
      After some talking to Alex and Michel, we decided to fix this
      by turning the double-check for asserted irq status bits into a
      warning. Whenever a irq event is queued in the IH ring, always
      execute the corresponding interrupt handler. Still check the irq
      status bits, but only to log a DRM_DEBUG message on a mismatch.
      
      This fixed the problems reliably on both previously failing
      cards, RV-730 dual-head tested on both crtcs (pipes D1 and D2)
      and a triple-output Juniper HD-5770 card tested on all three
      available crtcs (D1/D2/D3). The r600 and evergreen irq handling
      is therefore tested, but the cik an si handling is only compile
      tested due to lack of hw.
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      CC: Michel Dänzer <michel.daenzer@amd.com>
      CC: Alex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      [ luis: backported to 3.16:
        - dropped changes related with short HPD irqs as these are not
          supported in the 3.16 kernel ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      df93d3fe
    • Michal Hocko's avatar
      ext4: replace open coded nofail allocation in ext4_free_blocks() · 4057c3b6
      Michal Hocko authored
      commit 7444a072 upstream.
      
      ext4_free_blocks is looping around the allocation request and mimics
      __GFP_NOFAIL behavior without any allocation fallback strategy. Let's
      remove the open coded loop and replace it with __GFP_NOFAIL. Without the
      flag the allocator has no way to find out never-fail requirement and
      cannot help in any way.
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4057c3b6
    • Eryu Guan's avatar
      ext4: correctly migrate a file with a hole at the beginning · fed791b6
      Eryu Guan authored
      commit 8974fec7 upstream.
      
      Currently ext4_ind_migrate() doesn't correctly handle a file which
      contains a hole at the beginning of the file.  This caused the migration
      to be done incorrectly, and then if there is a subsequent following
      delayed allocation write to the "hole", this would reclaim the same data
      blocks again and results in fs corruption.
      
        # assmuing 4k block size ext4, with delalloc enabled
        # skip the first block and write to the second block
        xfs_io -fc "pwrite 4k 4k" -c "fsync" /mnt/ext4/testfile
      
        # converting to indirect-mapped file, which would move the data blocks
        # to the beginning of the file, but extent status cache still marks
        # that region as a hole
        chattr -e /mnt/ext4/testfile
      
        # delayed allocation writes to the "hole", reclaim the same data block
        # again, results in i_blocks corruption
        xfs_io -c "pwrite 0 4k" /mnt/ext4/testfile
        umount /mnt/ext4
        e2fsck -nf /dev/sda6
        ...
        Inode 53, i_blocks is 16, should be 8.  Fix? no
        ...
      Signed-off-by: default avatarEryu Guan <guaneryu@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      fed791b6
    • Eryu Guan's avatar
      ext4: be more strict when migrating to non-extent based file · 5d32c2e0
      Eryu Guan authored
      commit d6f123a9 upstream.
      
      Currently the check in ext4_ind_migrate() is not enough before doing the
      real conversion:
      
      a) delayed allocated extents could bypass the check on eh->eh_entries
         and eh->eh_depth
      
      This can be demonstrated by this script
      
        xfs_io -fc "pwrite 0 4k" -c "pwrite 8k 4k" /mnt/ext4/testfile
        chattr -e /mnt/ext4/testfile
      
      where testfile has two extents but still be converted to non-extent
      based file format.
      
      b) only extent length is checked but not the offset, which would result
         in data lose (delalloc) or fs corruption (nodelalloc), because
         non-extent based file only supports at most (12 + 2^10 + 2^20 + 2^30)
         blocks
      
      This can be demostrated by
      
        xfs_io -fc "pwrite 5T 4k" /mnt/ext4/testfile
        chattr -e /mnt/ext4/testfile
        sync
      
      If delalloc is enabled, dmesg prints
        EXT4-fs warning (device dm-4): ext4_block_to_path:105: block 1342177280 > max in inode 53
        EXT4-fs (dm-4): Delayed block allocation failed for inode 53 at logical offset 1342177280 with max blocks 1 with error 5
        EXT4-fs (dm-4): This should not happen!! Data will be lost
      
      If delalloc is disabled, e2fsck -nf shows corruption
        Inode 53, i_size is 5497558142976, should be 4096.  Fix? no
      
      Fix the two issues by
      
      a) forcing all delayed allocation blocks to be allocated before checking
         eh->eh_depth and eh->eh_entries
      b) limiting the last logical block of the extent is within direct map
      Signed-off-by: default avatarEryu Guan <guaneryu@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5d32c2e0
    • Lukas Czerner's avatar
      ext4: fix reservation release on invalidatepage for delalloc fs · e7f70bb6
      Lukas Czerner authored
      commit 9705acd6 upstream.
      
      On delalloc enabled file system on invalidatepage operation
      in ext4_da_page_release_reservation() we want to clear the delayed
      buffer and remove the extent covering the delayed buffer from the extent
      status tree.
      
      However currently there is a bug where on the systems with page size >
      block size we will always remove extents from the start of the page
      regardless where the actual delayed buffers are positioned in the page.
      This leads to the errors like this:
      
      EXT4-fs warning (device loop0): ext4_da_release_space:1225:
      ext4_da_release_space: ino 13, to_free 1 with only 0 reserved data
      blocks
      
      This however can cause data loss on writeback time if the file system is
      in ENOSPC condition because we're releasing reservation for someones
      else delayed buffer.
      
      Fix this by only removing extents that corresponds to the part of the
      page we want to invalidate.
      
      This problem is reproducible by the following fio receipt (however I was
      only able to reproduce it with fio-2.1 or older.
      
      [global]
      bs=8k
      iodepth=1024
      iodepth_batch=60
      randrepeat=1
      size=1m
      directory=/mnt/test
      numjobs=20
      [job1]
      ioengine=sync
      bs=1k
      direct=1
      rw=randread
      filename=file1:file2
      [job2]
      ioengine=libaio
      rw=randwrite
      direct=1
      filename=file1:file2
      [job3]
      bs=1k
      ioengine=posixaio
      rw=randwrite
      direct=1
      filename=file1:file2
      [job5]
      bs=1k
      ioengine=sync
      rw=randread
      filename=file1:file2
      [job7]
      ioengine=libaio
      rw=randwrite
      filename=file1:file2
      [job8]
      ioengine=posixaio
      rw=randwrite
      filename=file1:file2
      [job10]
      ioengine=mmap
      rw=randwrite
      bs=1k
      filename=file1:file2
      [job11]
      ioengine=mmap
      rw=randwrite
      direct=1
      filename=file1:file2
      Signed-off-by: default avatarLukas Czerner <lczerner@redhat.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e7f70bb6
    • Filipe Manana's avatar
      Btrfs: fix fsync data loss after append write · aa22af44
      Filipe Manana authored
      commit e4545de5 upstream.
      
      If we do an append write to a file (which increases its inode's i_size)
      that does not have the flag BTRFS_INODE_NEEDS_FULL_SYNC set in its inode,
      and the previous transaction added a new hard link to the file, which sets
      the flag BTRFS_INODE_COPY_EVERYTHING in the file's inode, and then fsync
      the file, the inode's new i_size isn't logged. This has the consequence
      that after the fsync log is replayed, the file size remains what it was
      before the append write operation, which means users/applications will
      not be able to read the data that was successsfully fsync'ed before.
      
      This happens because neither the inode item nor the delayed inode get
      their i_size updated when the append write is made - doing so would
      require starting a transaction in the buffered write path, something that
      we do not do intentionally for performance reasons.
      
      Fix this by making sure that when the flag BTRFS_INODE_COPY_EVERYTHING is
      set the inode is logged with its current i_size (log the in-memory inode
      into the log tree).
      
      This issue is not a recent regression and is easy to reproduce with the
      following test case for fstests:
      
        seq=`basename $0`
        seqres=$RESULT_DIR/$seq
        echo "QA output created by $seq"
      
        here=`pwd`
        tmp=/tmp/$$
        status=1	# failure is the default!
      
        _cleanup()
        {
                _cleanup_flakey
                rm -f $tmp.*
        }
        trap "_cleanup; exit \$status" 0 1 2 3 15
      
        # get standard environment, filters and checks
        . ./common/rc
        . ./common/filter
        . ./common/dmflakey
      
        # real QA test starts here
        _supported_fs generic
        _supported_os Linux
        _need_to_be_root
        _require_scratch
        _require_dm_flakey
        _require_metadata_journaling $SCRATCH_DEV
      
        _crash_and_mount()
        {
                # Simulate a crash/power loss.
                _load_flakey_table $FLAKEY_DROP_WRITES
                _unmount_flakey
                # Allow writes again and mount. This makes the fs replay its fsync log.
                _load_flakey_table $FLAKEY_ALLOW_WRITES
                _mount_flakey
        }
      
        rm -f $seqres.full
      
        _scratch_mkfs >> $seqres.full 2>&1
        _init_flakey
        _mount_flakey
      
        # Create the test file with some initial data and then fsync it.
        # The fsync here is only needed to trigger the issue in btrfs, as it causes the
        # the flag BTRFS_INODE_NEEDS_FULL_SYNC to be removed from the btrfs inode.
        $XFS_IO_PROG -f -c "pwrite -S 0xaa 0 32k" \
                        -c "fsync" \
                        $SCRATCH_MNT/foo | _filter_xfs_io
        sync
      
        # Add a hard link to our file.
        # On btrfs this sets the flag BTRFS_INODE_COPY_EVERYTHING on the btrfs inode,
        # which is a necessary condition to trigger the issue.
        ln $SCRATCH_MNT/foo $SCRATCH_MNT/bar
      
        # Sync the filesystem to force a commit of the current btrfs transaction, this
        # is a necessary condition to trigger the bug on btrfs.
        sync
      
        # Now append more data to our file, increasing its size, and fsync the file.
        # In btrfs because the inode flag BTRFS_INODE_COPY_EVERYTHING was set and the
        # write path did not update the inode item in the btree nor the delayed inode
        # item (in memory struture) in the current transaction (created by the fsync
        # handler), the fsync did not record the inode's new i_size in the fsync
        # log/journal. This made the data unavailable after the fsync log/journal is
        # replayed.
        $XFS_IO_PROG -c "pwrite -S 0xbb 32K 32K" \
                     -c "fsync" \
                     $SCRATCH_MNT/foo | _filter_xfs_io
      
        echo "File content after fsync and before crash:"
        od -t x1 $SCRATCH_MNT/foo
      
        _crash_and_mount
      
        echo "File content after crash and log replay:"
        od -t x1 $SCRATCH_MNT/foo
      
        status=0
        exit
      
      The expected file output before and after the crash/power failure expects the
      appended data to be available, which is:
      
        0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
        *
        0100000 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
        *
        0200000
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      aa22af44
    • Filipe Manana's avatar
      Btrfs: fix race between caching kthread and returning inode to inode cache · f8cd1ae6
      Filipe Manana authored
      commit ae9d8f17 upstream.
      
      While the inode cache caching kthread is calling btrfs_unpin_free_ino(),
      we could have a concurrent call to btrfs_return_ino() that adds a new
      entry to the root's free space cache of pinned inodes. This concurrent
      call does not acquire the fs_info->commit_root_sem before adding a new
      entry if the caching state is BTRFS_CACHE_FINISHED, which is a problem
      because the caching kthread calls btrfs_unpin_free_ino() after setting
      the caching state to BTRFS_CACHE_FINISHED and therefore races with
      the task calling btrfs_return_ino(), which is adding a new entry, while
      the former (caching kthread) is navigating the cache's rbtree, removing
      and freeing nodes from the cache's rbtree without acquiring the spinlock
      that protects the rbtree.
      
      This race resulted in memory corruption due to double free of struct
      btrfs_free_space objects because both tasks can end up doing freeing the
      same objects. Note that adding a new entry can result in merging it with
      other entries in the cache, in which case those entries are freed.
      This is particularly important as btrfs_free_space structures are also
      used for the block group free space caches.
      
      This memory corruption can be detected by a debugging kernel, which
      reports it with the following trace:
      
      [132408.501148] slab error in verify_redzone_free(): cache `btrfs_free_space': double free detected
      [132408.505075] CPU: 15 PID: 12248 Comm: btrfs-ino-cache Tainted: G        W       4.1.0-rc5-btrfs-next-10+ #1
      [132408.505075] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org 04/01/2014
      [132408.505075]  ffff880023e7d320 ffff880163d73cd8 ffffffff8145eec7 ffffffff81095dce
      [132408.505075]  ffff880009735d40 ffff880163d73ce8 ffffffff81154e1e ffff880163d73d68
      [132408.505075]  ffffffff81155733 ffffffffa054a95a ffff8801b6099f00 ffffffffa0505b5f
      [132408.505075] Call Trace:
      [132408.505075]  [<ffffffff8145eec7>] dump_stack+0x4f/0x7b
      [132408.505075]  [<ffffffff81095dce>] ? console_unlock+0x356/0x3a2
      [132408.505075]  [<ffffffff81154e1e>] __slab_error.isra.28+0x25/0x36
      [132408.505075]  [<ffffffff81155733>] __cache_free+0xe2/0x4b6
      [132408.505075]  [<ffffffffa054a95a>] ? __btrfs_add_free_space+0x2f0/0x343 [btrfs]
      [132408.505075]  [<ffffffffa0505b5f>] ? btrfs_unpin_free_ino+0x8e/0x99 [btrfs]
      [132408.505075]  [<ffffffff810f3b30>] ? time_hardirqs_off+0x15/0x28
      [132408.505075]  [<ffffffff81084d42>] ? trace_hardirqs_off+0xd/0xf
      [132408.505075]  [<ffffffff811563a1>] ? kfree+0xb6/0x14e
      [132408.505075]  [<ffffffff811563d0>] kfree+0xe5/0x14e
      [132408.505075]  [<ffffffffa0505b5f>] btrfs_unpin_free_ino+0x8e/0x99 [btrfs]
      [132408.505075]  [<ffffffffa0505e08>] caching_kthread+0x29e/0x2d9 [btrfs]
      [132408.505075]  [<ffffffffa0505b6a>] ? btrfs_unpin_free_ino+0x99/0x99 [btrfs]
      [132408.505075]  [<ffffffff8106698f>] kthread+0xef/0xf7
      [132408.505075]  [<ffffffff810f3b08>] ? time_hardirqs_on+0x15/0x28
      [132408.505075]  [<ffffffff810668a0>] ? __kthread_parkme+0xad/0xad
      [132408.505075]  [<ffffffff814653d2>] ret_from_fork+0x42/0x70
      [132408.505075]  [<ffffffff810668a0>] ? __kthread_parkme+0xad/0xad
      [132408.505075] ffff880023e7d320: redzone 1:0x9f911029d74e35b, redzone 2:0x9f911029d74e35b.
      [132409.501654] slab: double free detected in cache 'btrfs_free_space', objp ffff880023e7d320
      [132409.503355] ------------[ cut here ]------------
      [132409.504241] kernel BUG at mm/slab.c:2571!
      
      Therefore fix this by having btrfs_unpin_free_ino() acquire the lock
      that protects the rbtree while doing the searches and removing entries.
      
      Fixes: 1c70d8fb ("Btrfs: fix inode caching vs tree log")
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f8cd1ae6
    • Filipe Manana's avatar
      Btrfs: use kmem_cache_free when freeing entry in inode cache · 660fe0d6
      Filipe Manana authored
      commit c3f4a168 upstream.
      
      The free space entries are allocated using kmem_cache_zalloc(),
      through __btrfs_add_free_space(), therefore we should use
      kmem_cache_free() and not kfree() to avoid any confusion and
      any potential problem. Looking at the kfree() definition at
      mm/slab.c it has the following comment:
      
        /*
         * (...)
         *
         * Don't free memory not originally allocated by kmalloc()
         * or you will run into trouble.
         */
      
      So better be safe and use kmem_cache_free().
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.cz>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      660fe0d6