1. 31 Mar, 2016 10 commits
    • Joe Thornber's avatar
      dm cache: make sure every metadata function checks fail_io · d62e4330
      Joe Thornber authored
      commit d14fcf3d upstream.
      
      Otherwise operations may be attempted that will only ever go on to crash
      (since the metadata device is either missing or unreliable if 'fail_io'
      is set).
      Signed-off-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      d62e4330
    • Joe Thornber's avatar
      dm thin metadata: don't issue prefetches if a transaction abort has failed · c57e9e13
      Joe Thornber authored
      commit 2eae9e44 upstream.
      
      If a transaction abort has failed then we can no longer use the metadata
      device.  Typically this happens if the superblock is unreadable.
      
      This fix addresses a crash seen during metadata device failure testing.
      
      Fixes: 8a01a6af ("dm thin: prefetch missing metadata pages")
      Signed-off-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c57e9e13
    • DingXiang's avatar
      dm snapshot: disallow the COW and origin devices from being identical · e9a0e1c3
      DingXiang authored
      commit 4df2bf46 upstream.
      
      Otherwise loading a "snapshot" table using the same device for the
      origin and COW devices, e.g.:
      
      echo "0 20971520 snapshot 253:3 253:3 P 8" | dmsetup create snap
      
      will trigger:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
      [ 1958.979934] IP: [<ffffffffa040efba>] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot]
      [ 1958.989655] PGD 0
      [ 1958.991903] Oops: 0000 [#1] SMP
      ...
      [ 1959.059647] CPU: 9 PID: 3556 Comm: dmsetup Tainted: G          IO    4.5.0-rc5.snitm+ #150
      ...
      [ 1959.083517] task: ffff8800b9660c80 ti: ffff88032a954000 task.ti: ffff88032a954000
      [ 1959.091865] RIP: 0010:[<ffffffffa040efba>]  [<ffffffffa040efba>] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot]
      [ 1959.104295] RSP: 0018:ffff88032a957b30  EFLAGS: 00010246
      [ 1959.110219] RAX: 0000000000000000 RBX: 0000000000000008 RCX: 0000000000000001
      [ 1959.118180] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff880329334a00
      [ 1959.126141] RBP: ffff88032a957b50 R08: 0000000000000000 R09: 0000000000000001
      [ 1959.134102] R10: 000000000000000a R11: f000000000000000 R12: ffff880330884d80
      [ 1959.142061] R13: 0000000000000008 R14: ffffc90001c13088 R15: ffff880330884d80
      [ 1959.150021] FS:  00007f8926ba3840(0000) GS:ffff880333440000(0000) knlGS:0000000000000000
      [ 1959.159047] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1959.165456] CR2: 0000000000000098 CR3: 000000032f48b000 CR4: 00000000000006e0
      [ 1959.173415] Stack:
      [ 1959.175656]  ffffc90001c13040 ffff880329334a00 ffff880330884ed0 ffff88032a957bdc
      [ 1959.183946]  ffff88032a957bb8 ffffffffa040f225 ffff880329334a30 ffff880300000000
      [ 1959.192233]  ffffffffa04133e0 ffff880329334b30 0000000830884d58 00000000569c58cf
      [ 1959.200521] Call Trace:
      [ 1959.203248]  [<ffffffffa040f225>] dm_exception_store_create+0x1d5/0x240 [dm_snapshot]
      [ 1959.211986]  [<ffffffffa040d310>] snapshot_ctr+0x140/0x630 [dm_snapshot]
      [ 1959.219469]  [<ffffffffa0005c44>] ? dm_split_args+0x64/0x150 [dm_mod]
      [ 1959.226656]  [<ffffffffa0005ea7>] dm_table_add_target+0x177/0x440 [dm_mod]
      [ 1959.234328]  [<ffffffffa0009203>] table_load+0x143/0x370 [dm_mod]
      [ 1959.241129]  [<ffffffffa00090c0>] ? retrieve_status+0x1b0/0x1b0 [dm_mod]
      [ 1959.248607]  [<ffffffffa0009e35>] ctl_ioctl+0x255/0x4d0 [dm_mod]
      [ 1959.255307]  [<ffffffff813304e2>] ? memzero_explicit+0x12/0x20
      [ 1959.261816]  [<ffffffffa000a0c3>] dm_ctl_ioctl+0x13/0x20 [dm_mod]
      [ 1959.268615]  [<ffffffff81215eb6>] do_vfs_ioctl+0xa6/0x5c0
      [ 1959.274637]  [<ffffffff81120d2f>] ? __audit_syscall_entry+0xaf/0x100
      [ 1959.281726]  [<ffffffff81003176>] ? do_audit_syscall_entry+0x66/0x70
      [ 1959.288814]  [<ffffffff81216449>] SyS_ioctl+0x79/0x90
      [ 1959.294450]  [<ffffffff8167e4ae>] entry_SYSCALL_64_fastpath+0x12/0x71
      ...
      [ 1959.323277] RIP  [<ffffffffa040efba>] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot]
      [ 1959.333090]  RSP <ffff88032a957b30>
      [ 1959.336978] CR2: 0000000000000098
      [ 1959.344121] ---[ end trace b049991ccad1169e ]---
      
      Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1195899Signed-off-by: default avatarDing Xiang <dingxiang@huawei.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e9a0e1c3
    • Takashi Iwai's avatar
      ALSA: pcm: Avoid "BUG:" string for warnings again · b8c79744
      Takashi Iwai authored
      commit 0ab1ace8 upstream.
      
      The commit [d507941b: ALSA: pcm: Correct PCM BUG error message]
      made the warning prefix back to "BUG:" due to its previous wrong
      prefix.  But a kernel message containing "BUG:" seems taken as an Oops
      message wrongly by some brain-dead daemons, and it annoys users in the
      end.  Instead of teaching daemons, change the string again to a more
      reasonable one.
      
      Fixes: 507941beb1e ('ALSA: pcm: Correct PCM BUG error message')
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b8c79744
    • Dmitry Tunin's avatar
      Bluetooth: btusb: Add a new AR3012 ID 13d3:3472 · 5a9f7db3
      Dmitry Tunin authored
      commit 75c6aca4 upstream.
      
      T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
      D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
      P: Vendor=13d3 ProdID=3472 Rev=00.01
      C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      
      BugLink: https://bugs.launchpad.net/bugs/1552925Signed-off-by: default avatarDmitry Tunin <hanipouspilot@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5a9f7db3
    • Luck, Tony's avatar
      EDAC/sb_edac: Fix computation of channel address · b2944c72
      Luck, Tony authored
      commit eb1af3b7 upstream.
      
      Large memory Haswell-EX systems with multiple DIMMs per channel were
      sometimes reporting the wrong DIMM.
      
      Found three problems:
      
       1) Debug printouts for socket and channel interleave were not interpreting
          the register fields correctly. The socket interleave field is a 2^X
          value (0=1, 1=2, 2=4, 3=8). The channel interleave is X+1 (0=1, 1=2,
          2=3. 3=4).
      
       2) Actual use of the socket interleave value didn't interpret as 2^X
      
       3) Conversion of address to channel address was complicated, and wrong.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Acked-by: default avatarAristeu Rozanski <arozansk@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-edac@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b2944c72
    • Takashi Iwai's avatar
      ALSA: hda - Apply reboot D3 fix for CX20724 codec, too · 9dc52359
      Takashi Iwai authored
      commit 56dc66ff upstream.
      
      Just like CX20722, CX7024 codec also requires the power down at reboot
      in order to reduce the noise at reboot/shutdown.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=113511Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9dc52359
    • OGAWA Hirofumi's avatar
      jbd2: fix FS corruption possibility in jbd2_journal_destroy() on umount path · 77435ee8
      OGAWA Hirofumi authored
      commit c0a2ad9b upstream.
      
      On umount path, jbd2_journal_destroy() writes latest transaction ID
      (->j_tail_sequence) to be used at next mount.
      
      The bug is that ->j_tail_sequence is not holding latest transaction ID
      in some cases. So, at next mount, there is chance to conflict with
      remaining (not overwritten yet) transactions.
      
      	mount (id=10)
      	write transaction (id=11)
      	write transaction (id=12)
      	umount (id=10) <= the bug doesn't write latest ID
      
      	mount (id=10)
      	write transaction (id=11)
      	crash
      
      	mount
      	[recovery process]
      		transaction (id=11)
      		transaction (id=12) <= valid transaction ID, but old commit
                                             must not replay
      
      Like above, this bug become the cause of recovery failure, or FS
      corruption.
      
      So why ->j_tail_sequence doesn't point latest ID?
      
      Because if checkpoint transactions was reclaimed by memory pressure
      (i.e. bdev_try_to_free_page()), then ->j_tail_sequence is not updated.
      (And another case is, __jbd2_journal_clean_checkpoint_list() is called
      with empty transaction.)
      
      So in above cases, ->j_tail_sequence is not pointing latest
      transaction ID at umount path. Plus, REQ_FLUSH for checkpoint is not
      done too.
      
      So, to fix this problem with minimum changes, this patch updates
      ->j_tail_sequence, and issue REQ_FLUSH.  (With more complex changes,
      some optimizations would be possible to avoid unnecessary REQ_FLUSH
      for example though.)
      
      BTW,
      
      	journal->j_tail_sequence =
      		++journal->j_transaction_sequence;
      
      Increment of ->j_transaction_sequence seems to be unnecessary, but
      ext3 does this.
      Signed-off-by: default avatarOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      77435ee8
    • Douglas Gilbert's avatar
      sg: fix dxferp in from_to case · 44d941b3
      Douglas Gilbert authored
      commit 5ecee0a3 upstream.
      
      One of the strange things that the original sg driver did was let the
      user provide both a data-out buffer (it followed the sg_header+cdb)
      _and_ specify a reply length greater than zero. What happened was that
      the user data-out buffer was copied into some kernel buffers and then
      the mid level was told a read type operation would take place with the
      data from the device overwriting the same kernel buffers. The user would
      then read those kernel buffers back into the user space.
      
      From what I can tell, the above action was broken by commit fad7f01e
      ("sg: set dxferp to NULL for READ with the older SG interface") in 2008
      and syzkaller found that out recently.
      
      Make sure that a user space pointer is passed through when data follows
      the sg_header structure and command.  Fix the abnormal case when a
      non-zero reply_len is also given.
      
      Fixes: fad7f01eSigned-off-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
      Reviewed-by: default avatarEwan Milne <emilne@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      44d941b3
    • Mario Kleiner's avatar
      drm/radeon: Don't drop DP 2.7 Ghz link setup on some cards. · 970d0e14
      Mario Kleiner authored
      commit 459ee1c3 upstream.
      
      As observed on Apple iMac10,1, DCE-3.2, RV-730,
      link rate of 2.7 Ghz is not selected, because
      the args.v1.ucConfig flag setting for 2.7 Ghz
      gets overwritten by a following assignment of
      the transmitter to use.
      
      Move link rate setup a few lines down to fix this.
      In practice this didn't have any positive or
      negative effect on display setup on the tested
      iMac10,1 so i don't know if backporting to stable
      makes sense or not.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      970d0e14
  2. 30 Mar, 2016 30 commits