1. 19 Jun, 2015 5 commits
  2. 14 Apr, 2015 35 commits
    • Zefan Li's avatar
      Linux 3.4.107 · 56b48fcd
      Zefan Li authored
      56b48fcd
    • Myron Stowe's avatar
      PCI: Handle read-only BARs on AMD CS553x devices · d4e39382
      Myron Stowe authored
      commit 06cf35f9 upstream.
      
      Some AMD CS553x devices have read-only BARs because of a firmware or
      hardware defect.  There's a workaround in quirk_cs5536_vsa(), but it no
      longer works after 36e81648 ("PCI: Restore detection of read-only
      BARs").  Prior to 36e81648, we filled in res->start; afterwards we
      leave it zeroed out.  The quirk only updated the size, so the driver tried
      to use a region starting at zero, which didn't work.
      
      Expand quirk_cs5536_vsa() to read the base addresses from the BARs and
      hard-code the sizes.
      
      On Nix's system BAR 2's read-only value is 0x6200.  Prior to 36e81648,
      we interpret that as a 512-byte BAR based on the lowest-order bit set.  Per
      datasheet sec 5.6.1, that BAR (MFGPT) requires only 64 bytes; use that to
      avoid clearing any address bits if a platform uses only 64-byte alignment.
      
      [bhelgaas: changelog, reduce BAR 2 size to 64]
      Fixes: 36e81648 ("PCI: Restore detection of read-only BARs")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=85991#c4
      Link: http://support.amd.com/TechDocs/31506_cs5535_databook.pdf
      Link: http://support.amd.com/TechDocs/33238G_cs5536_db.pdfReported-and-tested-by: default avatarNix <nix@esperi.org.uk>
      Signed-off-by: default avatarMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      d4e39382
    • karl beldan's avatar
      lib/checksum.c: fix build for generic csum_tcpudp_nofold · be27fda7
      karl beldan authored
      commit 9ce35779 upstream.
      
      Fixed commit added from64to32 under _#ifndef do_csum_ but used it
      under _#ifndef csum_tcpudp_nofold_, breaking some builds (Fengguang's
      robot reported TILEGX's). Move from64to32 under the latter.
      
      Fixes: 150ae0e9 ("lib/checksum.c: fix carry in csum_tcpudp_nofold")
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarKarl Beldan <karl.beldan@rivierawaves.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      be27fda7
    • Leon Yu's avatar
      mm: fix anon_vma->degree underflow in anon_vma endless growing prevention · 972dafe0
      Leon Yu authored
      commit 3fe89b3e upstream.
      
      I have constantly stumbled upon "kernel BUG at mm/rmap.c:399!" after
      upgrading to 3.19 and had no luck with 4.0-rc1 neither.
      
      So, after looking into new logic introduced by commit 7a3ef208 ("mm:
      prevent endless growth of anon_vma hierarchy"), I found chances are that
      unlink_anon_vmas() is called without incrementing dst->anon_vma->degree
      in anon_vma_clone() due to allocation failure.  If dst->anon_vma is not
      NULL in error path, its degree will be incorrectly decremented in
      unlink_anon_vmas() and eventually underflow when exiting as a result of
      another call to unlink_anon_vmas().  That's how "kernel BUG at
      mm/rmap.c:399!" is triggered for me.
      
      This patch fixes the underflow by dropping dst->anon_vma when allocation
      fails.  It's safe to do so regardless of original value of dst->anon_vma
      because dst->anon_vma doesn't have valid meaning if anon_vma_clone()
      fails.  Besides, callers don't care dst->anon_vma in such case neither.
      
      Also suggested by Michal Hocko, we can clean up vma_adjust() a bit as
      anon_vma_clone() now does the work.
      
      [akpm@linux-foundation.org: tweak comment]
      Fixes: 7a3ef208 ("mm: prevent endless growth of anon_vma hierarchy")
      Signed-off-by: default avatarLeon Yu <chianglungyu@gmail.com>
      Signed-off-by: default avatarKonstantin Khlebnikov <koct9i@gmail.com>
      Reviewed-by: default avatarMichal Hocko <mhocko@suse.cz>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      972dafe0
    • Catalin Marinas's avatar
      net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour · 14b98571
      Catalin Marinas authored
      commit 91edd096 upstream.
      
      Commit db31c55a (net: clamp ->msg_namelen instead of returning an
      error) introduced the clamping of msg_namelen when the unsigned value
      was larger than sizeof(struct sockaddr_storage). This caused a
      msg_namelen of -1 to be valid. The native code was subsequently fixed by
      commit dbb490b9 (net: socket: error on a negative msg_namelen).
      
      In addition, the native code sets msg_namelen to 0 when msg_name is
      NULL. This was done in commit (6a2a2b3a net:socket: set msg_namelen
      to 0 if msg_name is passed as NULL in msghdr struct from userland) and
      subsequently updated by 08adb7da (fold verify_iovec() into
      copy_msghdr_from_user()).
      
      This patch brings the get_compat_msghdr() in line with
      copy_msghdr_from_user().
      
      Fixes: db31c55a (net: clamp ->msg_namelen instead of returning an error)
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [lizf: Backported to 3.4: s/uaddr/tmp1/]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      14b98571
    • Ryusuke Konishi's avatar
      nilfs2: fix deadlock of segment constructor during recovery · a4cb7e34
      Ryusuke Konishi authored
      commit 283ee148 upstream.
      
      According to a report from Yuxuan Shui, nilfs2 in kernel 3.19 got stuck
      during recovery at mount time.  The code path that caused the deadlock was
      as follows:
      
        nilfs_fill_super()
          load_nilfs()
            nilfs_salvage_orphan_logs()
              * Do roll-forwarding, attach segment constructor for recovery,
                and kick it.
      
              nilfs_segctor_thread()
                nilfs_segctor_thread_construct()
                 * A lock is held with nilfs_transaction_lock()
                   nilfs_segctor_do_construct()
                     nilfs_segctor_drop_written_files()
                       iput()
                         iput_final()
                           write_inode_now()
                             writeback_single_inode()
                               __writeback_single_inode()
                                 do_writepages()
                                   nilfs_writepage()
                                     nilfs_construct_dsync_segment()
                                       nilfs_transaction_lock() --> deadlock
      
      This can happen if commit 7ef3ff2f ("nilfs2: fix deadlock of segment
      constructor over I_SYNC flag") is applied and roll-forward recovery was
      performed at mount time.  The roll-forward recovery can happen if datasync
      write is done and the file system crashes immediately after that.  For
      instance, we can reproduce the issue with the following steps:
      
       < nilfs2 is mounted on /nilfs (device: /dev/sdb1) >
       # dd if=/dev/zero of=/nilfs/test bs=4k count=1 && sync
       # dd if=/dev/zero of=/nilfs/test conv=notrunc oflag=dsync bs=4k
       count=1 && reboot -nfh
       < the system will immediately reboot >
       # mount -t nilfs2 /dev/sdb1 /nilfs
      
      The deadlock occurs because iput() can run segment constructor through
      writeback_single_inode() if MS_ACTIVE flag is not set on sb->s_flags.  The
      above commit changed segment constructor so that it calls iput()
      asynchronously for inodes with i_nlink == 0, but that change was
      imperfect.
      
      This fixes the another deadlock by deferring iput() in segment constructor
      even for the case that mount is not finished, that is, for the case that
      MS_ACTIVE flag is not set.
      Signed-off-by: default avatarRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Reported-by: default avatarYuxuan Shui <yshuiv7@gmail.com>
      Tested-by: default avatarRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      a4cb7e34
    • Andy Shevchenko's avatar
      spi: dw: revisit FIFO size detection again · 8b19cfea
      Andy Shevchenko authored
      commit 9d239d35 upstream.
      
      The commit d297933c (spi: dw: Fix detecting FIFO depth) tries to fix the
      logic of the FIFO detection based on the description on the comments. However,
      there is a slight difference between numbers in TX Level and TX FIFO size.
      
      So, by specification the FIFO size would be in a range 2-256 bytes. From TX
      Level prospective it means we can set threshold in the range 0-(FIFO size - 1)
      bytes. Hence there are currently two issues:
        a) FIFO size 2 bytes is actually skipped since TX Level is 1 bit and could be
           either 0 or 1 byte;
        b) FIFO size is incorrectly decreased by 1 which already done by meaning of
           TX Level register.
      
      This patch fixes it eventually right.
      
      Fixes: d297933c (spi: dw: Fix detecting FIFO depth)
      Reviewed-by: default avatarAxel Lin <axel.lin@ingics.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      8b19cfea
    • John Stultz's avatar
      ntp: Fixup adjtimex freq validation on 32-bit systems · f8cce9e3
      John Stultz authored
      commit 29183a70 upstream.
      
      Additional validation of adjtimex freq values to avoid
      potential multiplication overflows were added in commit
      5e5aeb43 (time: adjtimex: Validate the ADJ_FREQUENCY values)
      
      Unfortunately the patch used LONG_MAX/MIN instead of
      LLONG_MAX/MIN, which was fine on 64-bit systems, but being
      much smaller on 32-bit systems caused false positives
      resulting in most direct frequency adjustments to fail w/
      EINVAL.
      
      ntpd only does direct frequency adjustments at startup, so
      the issue was not as easily observed there, but other time
      sync applications like ptpd and chrony were more effected by
      the bug.
      
      See bugs:
      
        https://bugzilla.kernel.org/show_bug.cgi?id=92481
        https://bugzilla.redhat.com/show_bug.cgi?id=1188074
      
      This patch changes the checks to use LLONG_MAX for
      clarity, and additionally the checks are disabled
      on 32-bit systems since LLONG_MAX/PPM_SCALE is always
      larger then the 32-bit long freq value, so multiplication
      overflows aren't possible there.
      Reported-by: default avatarJosh Boyer <jwboyer@fedoraproject.org>
      Reported-by: default avatarGeorge Joseph <george.joseph@fairview5.com>
      Tested-by: default avatarGeorge Joseph <george.joseph@fairview5.com>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Link: http://lkml.kernel.org/r/1423553436-29747-1-git-send-email-john.stultz@linaro.org
      [ Prettified the changelog and the comments a bit. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      f8cce9e3
    • Martin Schwidefsky's avatar
      s390/3215: fix tty output containing tabs · 9493ef4e
      Martin Schwidefsky authored
      commit e512d56c upstream.
      
      git commit 37f81fa1
      "n_tty: do O_ONLCR translation as a single write"
      surfaced a bug in the 3215 device driver. In combination this
      broke tab expansion for tty ouput.
      
      The cause is an asymmetry in the behaviour of tty3215_ops->write
      vs tty3215_ops->put_char. The put_char function scans for '\t'
      but the write function does not.
      
      As the driver has logic for the '\t' expansion remove XTABS
      from c_oflag of the initial termios as well.
      Reported-by: default avatarStephen Powell <zlinuxman@wowway.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      9493ef4e
    • Borislav Petkov's avatar
      x86, cpu, amd: Add workaround for family 16h, erratum 793 · 56a59c3e
      Borislav Petkov authored
      commit 3b564968 upstream.
      
      This adds the workaround for erratum 793 as a precaution in case not
      every BIOS implements it.  This addresses CVE-2013-6885.
      
      Erratum text:
      
      [Revision Guide for AMD Family 16h Models 00h-0Fh Processors,
      document 51810 Rev. 3.04 November 2013]
      
      793 Specific Combination of Writes to Write Combined Memory Types and
      Locked Instructions May Cause Core Hang
      
      Description
      
      Under a highly specific and detailed set of internal timing
      conditions, a locked instruction may trigger a timing sequence whereby
      the write to a write combined memory type is not flushed, causing the
      locked instruction to stall indefinitely.
      
      Potential Effect on System
      
      Processor core hang.
      
      Suggested Workaround
      
      BIOS should set MSR
      C001_1020[15] = 1b.
      
      Fix Planned
      
      No fix planned
      
      [ hpa: updated description, fixed typo in MSR name ]
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/20140114230711.GS29865@pd.tnicTested-by: default avatarAravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      [bwh: Backported to 3.2:
       - Adjust filename
       - Venkatesh Srinivas pointed out we should use {rd,wr}msrl_safe() to
         avoid crashing on KVM.  This was fixed upstream by commit 8f86a737
         ("x86, AMD: Convert to the new bit access MSR accessors") but that's too
         much trouble to backport.  Here we must use {rd,wr}msrl_amd_safe().]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Cc: Moritz Muehlenhoff <jmm@debian.org>
      Cc: Venkatesh Srinivas <venkateshs@google.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      56a59c3e
    • Jerry Hoemann's avatar
      fsnotify: next_i is freed during fsnotify_unmount_inodes. · 917a35f6
      Jerry Hoemann authored
      commit 6424babf upstream.
      
      During file system stress testing on 3.10 and 3.12 based kernels, the
      umount command occasionally hung in fsnotify_unmount_inodes in the
      section of code:
      
                      spin_lock(&inode->i_lock);
                      if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW)) {
                              spin_unlock(&inode->i_lock);
                              continue;
                      }
      
      As this section of code holds the global inode_sb_list_lock, eventually
      the system hangs trying to acquire the lock.
      
      Multiple crash dumps showed:
      
      The inode->i_state == 0x60 and i_count == 0 and i_sb_list would point
      back at itself.  As this is not the value of list upon entry to the
      function, the kernel never exits the loop.
      
      To help narrow down problem, the call to list_del_init in
      inode_sb_list_del was changed to list_del.  This poisons the pointers in
      the i_sb_list and causes a kernel to panic if it transverse a freed
      inode.
      
      Subsequent stress testing paniced in fsnotify_unmount_inodes at the
      bottom of the list_for_each_entry_safe loop showing next_i had become
      free.
      
      We believe the root cause of the problem is that next_i is being freed
      during the window of time that the list_for_each_entry_safe loop
      temporarily releases inode_sb_list_lock to call fsnotify and
      fsnotify_inode_delete.
      
      The code in fsnotify_unmount_inodes attempts to prevent the freeing of
      inode and next_i by calling __iget.  However, the code doesn't do the
      __iget call on next_i
      
      	if i_count == 0 or
      	if i_state & (I_FREEING | I_WILL_FREE)
      
      The patch addresses this issue by advancing next_i in the above two cases
      until we either find a next_i which we can __iget or we reach the end of
      the list.  This makes the handling of next_i more closely match the
      handling of the variable "inode."
      
      The time to reproduce the hang is highly variable (from hours to days.) We
      ran the stress test on a 3.10 kernel with the proposed patch for a week
      without failure.
      
      During list_for_each_entry_safe, next_i is becoming free causing
      the loop to never terminate.  Advance next_i in those cases where
      __iget is not done.
      Signed-off-by: default avatarJerry Hoemann <jerry.hoemann@hp.com>
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Ken Helias <kenhelias@firemail.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      917a35f6
    • Ani Sinha's avatar
      net:socket: set msg_namelen to 0 if msg_name is passed as NULL in msghdr struct from userland. · adc50768
      Ani Sinha authored
      commit 6a2a2b3a upstream.
      
      Linux manpage for recvmsg and sendmsg calls does not explicitly mention setting msg_namelen to 0 when
      msg_name passed set as NULL. When developers don't set msg_namelen member in msghdr, it might contain garbage
      value which will fail the validation check and sendmsg and recvmsg calls from kernel will return EINVAL. This will
      break old binaries and any code for which there is no access to source code.
      To fix this, we set msg_namelen to 0 when msg_name is passed as NULL from userland.
      Signed-off-by: default avatarAni Sinha <ani@arista.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Michal Marek <mmarek@suse.cz>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      adc50768
    • Tim Chen's avatar
      sched/rt: Reduce rq lock contention by eliminating locking of non-feasible target · 590603b7
      Tim Chen authored
      commit 80e3d87b upstream.
      
      This patch adds checks that prevens futile attempts to move rt tasks
      to a CPU with active tasks of equal or higher priority.
      
      This reduces run queue lock contention and improves the performance of
      a well known OLTP benchmark by 0.7%.
      Signed-off-by: default avatarTim Chen <tim.c.chen@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Shawn Bohrer <sbohrer@rgmadvisors.com>
      Cc: Suruchi Kadu <suruchi.a.kadu@intel.com>
      Cc: Doug Nelson<doug.nelson@intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1421430374.2399.27.camel@schen9-desk2.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      590603b7
    • Adam Lee's avatar
      Bluetooth: ath3k: workaround the compatibility issue with xHCI controller · c12b6db9
      Adam Lee authored
      commit c561a575 upstream.
      
      BugLink: https://bugs.launchpad.net/bugs/1400215
      
      ath3k devices fail to load firmwares on xHCI buses, but work well on
      EHCI, this might be a compatibility issue between xHCI and ath3k chips.
      As my testing result, those chips will work on xHCI buses again with
      this patch.
      
      This workaround is from Qualcomm, they also did some workarounds in
      Windows driver.
      Signed-off-by: default avatarAdam Lee <adam.lee@canonical.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      c12b6db9
    • Ian Abbott's avatar
      staging: comedi: cb_pcidas64: fix incorrect AI range code handling · 3d05f9f3
      Ian Abbott authored
      commit be8e8908 upstream.
      
      The hardware range code values and list of valid ranges for the AI
      subdevice is incorrect for several supported boards.  The hardware range
      code values for all boards except PCI-DAS4020/12 is determined by
      calling `ai_range_bits_6xxx()` based on the maximum voltage of the range
      and whether it is bipolar or unipolar, however it only returns the
      correct hardware range code for the PCI-DAS60xx boards.  For
      PCI-DAS6402/16 (and /12) it returns the wrong code for the unipolar
      ranges.  For PCI-DAS64/Mx/16 it returns the wrong code for all the
      ranges and the comedi range table is incorrect.
      
      Change `ai_range_bits_6xxx()` to use a look-up table pointed to by new
      member `ai_range_codes` of `struct pcidas64_board` to map the comedi
      range table indices to the hardware range codes.  Use a new comedi range
      table for the PCI-DAS64/Mx/16 boards (and the commented out variants).
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [Ian: Backported to 3.4]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      3d05f9f3
    • Julian Anastasov's avatar
      ipvs: rerouting to local clients is not needed anymore · f0a6690e
      Julian Anastasov authored
      commit 579eb62a upstream.
      
      commit f5a41847 ("ipvs: move ip_route_me_harder for ICMP")
      from 2.6.37 introduced ip_route_me_harder() call for responses to
      local clients, so that we can provide valid rt_src after SNAT.
      It was used by TCP to provide valid daddr for ip_send_reply().
      After commit 0a5ebb80 ("ipv4: Pass explicit daddr arg to
      ip_send_reply()." from 3.0 this rerouting is not needed anymore
      and should be avoided, especially in LOCAL_IN.
      
      Fixes 3.12.33 crash in xfrm reported by Florian Wiessner:
      "3.12.33 - BUG xfrm_selector_match+0x25/0x2f6"
      Reported-by: default avatarSmart Weblications GmbH - Florian Wiessner <f.wiessner@smart-weblications.de>
      Tested-by: default avatarSmart Weblications GmbH - Florian Wiessner <f.wiessner@smart-weblications.de>
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      [Julian: Backported to 3.4]
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Acked-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      f0a6690e
    • Dave Kleikamp's avatar
      jfs: fix readdir regression · 72910542
      Dave Kleikamp authored
      Upstream commit 44512449, "jfs: fix readdir cookie incompatibility
      with NFSv4", was backported incorrectly into the stable trees which
      used the filldir callback (rather than dir_emit). The position is
      being incorrectly passed to filldir for the . and .. entries.
      
      The still-maintained stable trees that need to be fixed are 3.2.y,
      3.4.y and 3.10.y.
      
      https://bugzilla.kernel.org/show_bug.cgi?id=94741Signed-off-by: default avatarDave Kleikamp <dave.kleikamp@oracle.com>
      Cc: jfs-discussion@lists.sourceforge.net
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      72910542
    • Tim Niemeyer's avatar
      Bluetooth: Fix invalid length check in l2cap_information_rsp() · fd3fc802
      Tim Niemeyer authored
      first backport commit 6ec88fcb changes
      l2cap_move_channel_confirm_rsp and not the l2cap_information_rsp. So
      revert this and fix at the correct position.
      
      commit 3f6fa3d4 upstream.
      
      The length check is invalid since the length varies with type of
      info response.
      
      This was introduced by the commit cb3b3152
      
      Because of this, l2cap info rsp is not handled and command reject is sent.
      
      > ACL data: handle 11 flags 0x02 dlen 16
              L2CAP(s): Info rsp: type 2 result 0
                Extended feature mask 0x00b8
                  Enhanced Retransmission mode
                  Streaming mode
                  FCS Option
                  Fixed Channels
      < ACL data: handle 11 flags 0x00 dlen 10
              L2CAP(s): Command rej: reason 0
                Command not understood
      Signed-off-by: default avatarJaganath Kanakkassery <jaganath.k@samsung.com>
      Signed-off-by: default avatarChan-Yeol Park <chanyeol.park@samsung.com>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Cc: Jianguo Wu <wujianguo@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarTim Niemeyer <tim.niemeyer@corscience.de>
      Acked-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      fd3fc802
    • Kirill A. Shutemov's avatar
      pagemap: do not leak physical addresses to non-privileged userspace · 6a688d1c
      Kirill A. Shutemov authored
      commit ab676b7d upstream.
      
      As pointed by recent post[1] on exploiting DRAM physical imperfection,
      /proc/PID/pagemap exposes sensitive information which can be used to do
      attacks.
      
      This disallows anybody without CAP_SYS_ADMIN to read the pagemap.
      
      [1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
      
      [ Eventually we might want to do anything more finegrained, but for now
        this is the simple model.   - Linus ]
      Signed-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: default avatarKonstantin Khlebnikov <khlebnikov@openvz.org>
      Acked-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Mark Seaborn <mseaborn@chromium.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      [mancha: Backported to 3.10]
      Signed-off-by: default avatarmancha security <mancha1@zoho.com>
      6a688d1c
    • Janne Heikkinen's avatar
      Bluetooth: Add USB device 04ca:3010 as Atheros AR3012 · 3022d3dd
      Janne Heikkinen authored
      commit 134d3b35 upstream.
      
      Asus X553MA has USB device 04ca:3010 that is Atheros AR3012
      or compatible.
      
      Device from /sys/kernel/debug/usb/devices:
      
      T:  Bus=01 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 27 Spd=12   MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=04ca ProdID=3010 Rev= 0.02
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      Signed-off-by: default avatarJanne Heikkinen <janne.m.heikkinen@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      [lizf: Backported to 3.4: adjust context]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      3022d3dd
    • Dmitry Tunin's avatar
      Bluetooth: ath3k: Add support of MCI 13d3:3408 bt device · 7461373f
      Dmitry Tunin authored
      commit 3bb30a7c upstream.
      
      Add support for Bluetooth MCI WB335 (AR9565) Wi-Fi+bt module. This
      Bluetooth module requires loading patch and sysconfig by ath3k driver.
      
      T:  Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 20 Spd=12   MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=13d3 ProdID=3408 Rev= 0.02
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      Signed-off-by: default avatarDmitry Tunin <hanipouspilot@gmail.com>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      7461373f
    • Anantha Krishnan's avatar
      Bluetooth: Add support for Acer [0489:e078] · 94a30505
      Anantha Krishnan authored
      commit 4b552bc9 upstream.
      
      Add support for the QCA6174 chip.
      
          T:  Bus=06 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
          D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
          P:  Vendor=0489 ProdID=e078 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
      Signed-off-by: default avatarAnantha Krishnan <ananthk@codeaurora.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Cc: Joseph Salisbury <joseph.salisbury@canonical.com>
      [lizf: Backported to 3.4: adjust context]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      94a30505
    • Vincent Zwanenburg's avatar
      Add a new PID/VID 0227/0930 for AR3012. · a756fa64
      Vincent Zwanenburg authored
      commit 89d2975f upstream.
      
      usb devices info:
      
      T:  Bus=01 Lev=02 Prnt=05 Port=00 Cnt=01 Dev#= 20 Spd=12   MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0930 ProdID=0227 Rev= 0.02
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      Signed-off-by: default avatarVincent Zwanenburg <vincentz@topmail.ie>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      [lizf: Backported to 3.4: adjust context]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      a756fa64
    • Marcel Holtmann's avatar
      Bluetooth: Add support for Broadcom device of Asus Z97-DELUXE motherboard · c96bfe4a
      Marcel Holtmann authored
      commit c2aef6e8 upstream.
      
      The Asus Z97-DELUXE motherboard contains a Broadcom based Bluetooth
      controller on the USB bus. However vendor and product ID are listed
      as ASUSTek Computer.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0b05 ProdID=17cf Rev= 1.12
      S:  Manufacturer=Broadcom Corp
      S:  Product=BCM20702A0
      S:  SerialNumber=54271E910064
      C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=  0mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
      Reported-by: default avatarJerome Leclanche <jerome@leclan.ch>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      [lizf: Backported to 3.4: adjust context]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      c96bfe4a
    • Anantha Krishnan's avatar
      Bluetooth: Add support for Acer [13D3:3432] · 394c1f2d
      Anantha Krishnan authored
      commit fa2f1394 upstream.
      
      Add support for the QCA6174 chip.
      
          T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 30 Spd=12  MxCh= 0
          D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
          P:  Vendor=13d3 ProdID=3432 Rev=00.02
          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
      Signed-off-by: default avatarAnantha Krishnan <ananthk@codeaurora.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      394c1f2d
    • Marcel Holtmann's avatar
      Bluetooth: Ignore isochronous endpoints for Intel USB bootloader · afe1e020
      Marcel Holtmann authored
      commit d92f2df0 upstream.
      
      The isochronous endpoints are not valid when the Intel Bluetooth
      controller boots up in bootloader mode. So just mark these endpoints
      as broken and then they will not be configured.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      afe1e020
    • Marcel Holtmann's avatar
      Bluetooth: Add support for Intel bootloader devices · a566d177
      Marcel Holtmann authored
      commit 40df783d upstream.
      
      Intel Bluetooth devices that boot up in bootloader mode can not
      be used as generic HCI devices, but their HCI transport is still
      valuable and so bring that up as raw-only devices.
      
      T:  Bus=02 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 14 Spd=12   MxCh= 0
      D:  Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=8087 ProdID=0a5a Rev= 0.00
      S:  Manufacturer=Intel(R) Corporation
      S:  Product=Intel(R) Wilkins Peak 2x2
      S:  SerialNumber=001122334455 WP_A0
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      [lizf: Backported to 3.4: there's no BTUSB_BCM_PATCHRAM]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      a566d177
    • Andy Shevchenko's avatar
      Bluetooth: append new supported device to the list [0b05:17d0] · e9c6ffea
      Andy Shevchenko authored
      commit a735f9e2 upstream.
      
      The device found on Asus Z87 Expert motherboard requires firmware to work
      correctly.
      
      T:  Bus=03 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0b05 ProdID=17d0 Rev=00.02
      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
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      [lizf: Backported to 3.4: adjust context]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      e9c6ffea
    • Andy Shevchenko's avatar
      Bluetooth: sort the list of IDs in the source code · 75aac82d
      Andy Shevchenko authored
      commit 0b880062 upstream.
      
      This will help to manage table of supported IDs.
      
      There is no functional change.
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      [lizf: Backported to 3.4: sort the list by myself]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      75aac82d
    • Fernando Soto's avatar
      Drivers: hv: vmbus: incorrect device name is printed when child device is unregistered · 7191cb93
      Fernando Soto authored
      commit 84672369 upstream.
      
      Whenever a device is unregistered in vmbus_device_unregister (drivers/hv/vmbus_drv.c), the device name in the log message may contain garbage as the memory has already been freed by the time pr_info is called. Log example:
       [ 3149.170475] hv_vmbus: child device àõsèè0_5 unregistered
      
      By logging the message just before calling device_unregister, the correct device name is printed:
      [ 3145.034652] hv_vmbus: child device vmbus_0_5 unregistered
      
      Also changing register & unregister messages to debug to avoid unnecessarily cluttering the kernel log.
      Signed-off-by: default avatarFernando M Soto <fsoto@bluecatnetworks.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Joseph Salisbury <joseph.salisbury@canonical.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      7191cb93
    • Ryusuke Konishi's avatar
      nilfs2: fix deadlock of segment constructor over I_SYNC flag · 28cd54f2
      Ryusuke Konishi authored
      commit 7ef3ff2f upstream.
      
      Nilfs2 eventually hangs in a stress test with fsstress program.  This
      issue was caused by the following deadlock over I_SYNC flag between
      nilfs_segctor_thread() and writeback_sb_inodes():
      
        nilfs_segctor_thread()
          nilfs_segctor_thread_construct()
            nilfs_segctor_unlock()
              nilfs_dispose_list()
                iput()
                  iput_final()
                    evict()
                      inode_wait_for_writeback()  * wait for I_SYNC flag
      
        writeback_sb_inodes()
           * set I_SYNC flag on inode->i_state
          __writeback_single_inode()
            do_writepages()
              nilfs_writepages()
                nilfs_construct_dsync_segment()
                  nilfs_segctor_sync()
                     * wait for completion of segment constructor
          inode_sync_complete()
             * clear I_SYNC flag after __writeback_single_inode() completed
      
      writeback_sb_inodes() calls do_writepages() for dirty inodes after
      setting I_SYNC flag on inode->i_state.  do_writepages() in turn calls
      nilfs_writepages(), which can run segment constructor and wait for its
      completion.  On the other hand, segment constructor calls iput(), which
      can call evict() and wait for the I_SYNC flag on
      inode_wait_for_writeback().
      
      Since segment constructor doesn't know when I_SYNC will be set, it
      cannot know whether iput() will block or not unless inode->i_nlink has a
      non-zero count.  We can prevent evict() from being called in iput() by
      implementing sop->drop_inode(), but it's not preferable to leave inodes
      with i_nlink == 0 for long periods because it even defers file
      truncation and inode deallocation.  So, this instead resolves the
      deadlock by calling iput() asynchronously with a workqueue for inodes
      with i_nlink == 0.
      Signed-off-by: default avatarRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Tested-by: default avatarRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      28cd54f2
    • Eric Nelson's avatar
      ASoC: sgtl5000: add delay before first I2C access · 708ef337
      Eric Nelson authored
      commit 58cc9c9a upstream.
      
      To quote from section 1.3.1 of the data sheet:
      	The SGTL5000 has an internal reset that is deasserted
      	8 SYS_MCLK cycles after all power rails have been brought
      	up. After this time, communication can start
      
      	...
      	1.0us represents 8 SYS_MCLK cycles at the minimum 8.0 MHz SYS_MCLK.
      Signed-off-by: default avatarEric Nelson <eric.nelson@boundarydevices.com>
      Reviewed-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      708ef337
    • Saran Maruti Ramanara's avatar
      net: sctp: fix passing wrong parameter header to param_type2af in sctp_process_param · 6b4a9a08
      Saran Maruti Ramanara authored
      commit cfbf654e upstream.
      
      When making use of RFC5061, section 4.2.4. for setting the primary IP
      address, we're passing a wrong parameter header to param_type2af(),
      resulting always in NULL being returned.
      
      At this point, param.p points to a sctp_addip_param struct, containing
      a sctp_paramhdr (type = 0xc004, length = var), and crr_id as a correlation
      id. Followed by that, as also presented in RFC5061 section 4.2.4., comes
      the actual sctp_addr_param, which also contains a sctp_paramhdr, but
      this time with the correct type SCTP_PARAM_IPV{4,6}_ADDRESS that
      param_type2af() can make use of. Since we already hold a pointer to
      addr_param from previous line, just reuse it for param_type2af().
      
      Fixes: d6de3097 ("[SCTP]: Add the handling of "Set Primary IP Address" parameter to INIT")
      Signed-off-by: default avatarSaran Maruti Ramanara <saran.neti@telus.com>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      6b4a9a08
    • Daniel Borkmann's avatar
      net: sctp: fix NULL pointer dereference in af->from_addr_param on malformed packet · 999a6c8f
      Daniel Borkmann authored
      commit e40607cb upstream.
      
      An SCTP server doing ASCONF will panic on malformed INIT ping-of-death
      in the form of:
      
        ------------ INIT[PARAM: SET_PRIMARY_IP] ------------>
      
      While the INIT chunk parameter verification dissects through many things
      in order to detect malformed input, it misses to actually check parameters
      inside of parameters. E.g. RFC5061, section 4.2.4 proposes a 'set primary
      IP address' parameter in ASCONF, which has as a subparameter an address
      parameter.
      
      So an attacker may send a parameter type other than SCTP_PARAM_IPV4_ADDRESS
      or SCTP_PARAM_IPV6_ADDRESS, param_type2af() will subsequently return 0
      and thus sctp_get_af_specific() returns NULL, too, which we then happily
      dereference unconditionally through af->from_addr_param().
      
      The trace for the log:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000078
      IP: [<ffffffffa01e9c62>] sctp_process_init+0x492/0x990 [sctp]
      PGD 0
      Oops: 0000 [#1] SMP
      [...]
      Pid: 0, comm: swapper Not tainted 2.6.32-504.el6.x86_64 #1 Bochs Bochs
      RIP: 0010:[<ffffffffa01e9c62>]  [<ffffffffa01e9c62>] sctp_process_init+0x492/0x990 [sctp]
      [...]
      Call Trace:
       <IRQ>
       [<ffffffffa01f2add>] ? sctp_bind_addr_copy+0x5d/0xe0 [sctp]
       [<ffffffffa01e1fcb>] sctp_sf_do_5_1B_init+0x21b/0x340 [sctp]
       [<ffffffffa01e3751>] sctp_do_sm+0x71/0x1210 [sctp]
       [<ffffffffa01e5c09>] ? sctp_endpoint_lookup_assoc+0xc9/0xf0 [sctp]
       [<ffffffffa01e61f6>] sctp_endpoint_bh_rcv+0x116/0x230 [sctp]
       [<ffffffffa01ee986>] sctp_inq_push+0x56/0x80 [sctp]
       [<ffffffffa01fcc42>] sctp_rcv+0x982/0xa10 [sctp]
       [<ffffffffa01d5123>] ? ipt_local_in_hook+0x23/0x28 [iptable_filter]
       [<ffffffff8148bdc9>] ? nf_iterate+0x69/0xb0
       [<ffffffff81496d10>] ? ip_local_deliver_finish+0x0/0x2d0
       [<ffffffff8148bf86>] ? nf_hook_slow+0x76/0x120
       [<ffffffff81496d10>] ? ip_local_deliver_finish+0x0/0x2d0
      [...]
      
      A minimal way to address this is to check for NULL as we do on all
      other such occasions where we know sctp_get_af_specific() could
      possibly return with NULL.
      
      Fixes: d6de3097 ("[SCTP]: Add the handling of "Set Primary IP Address" parameter to INIT")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      999a6c8f
    • Johan Hovold's avatar
      gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low · 2e835e9f
      Johan Hovold authored
      commit 49d2ca84 upstream.
      
      Fix memory leak in the gpio sysfs interface due to failure to drop
      reference to device returned by class_find_device when setting the
      gpio-line polarity.
      
      Fixes: 07697461 ("gpiolib: add support for changing value polarity
      in sysfs")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      [lizf: Backported to 3.4: adjust filename]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      2e835e9f