1. 19 Jun, 2015 28 commits
    • Naoya Horiguchi's avatar
      mm/hugetlb: add migration/hwpoisoned entry check in hugetlb_change_protection · 13645c4a
      Naoya Horiguchi authored
      commit a8bda28d upstream.
      
      There is a race condition between hugepage migration and
      change_protection(), where hugetlb_change_protection() doesn't care about
      migration entries and wrongly overwrites them.  That causes unexpected
      results like kernel crash.  HWPoison entries also can cause the same
      problem.
      
      This patch adds is_hugetlb_entry_(migration|hwpoisoned) check in this
      function to do proper actions.
      
      Fixes: 290408d4 ("hugetlb: hugepage migration core")
      Signed-off-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Luiz Capitulino <lcapitulino@redhat.com>
      Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Cc: Steve Capper <steve.capper@linaro.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [lizf: Backported to 3.4:
       - remove locking of ptl
       - remove counting of pages]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      13645c4a
    • Naoya Horiguchi's avatar
      mm/hugetlb: fix getting refcount 0 page in hugetlb_fault() · 027d8328
      Naoya Horiguchi authored
      commit 0f792cf9 upstream.
      
      When running the test which causes the race as shown in the previous patch,
      we can hit the BUG "get_page() on refcount 0 page" in hugetlb_fault().
      
      This race happens when pte turns into migration entry just after the first
      check of is_hugetlb_entry_migration() in hugetlb_fault() passed with false.
      To fix this, we need to check pte_present() again after huge_ptep_get().
      
      This patch also reorders taking ptl and doing pte_page(), because
      pte_page() should be done in ptl.  Due to this reordering, we need use
      trylock_page() in page != pagecache_page case to respect locking order.
      
      Fixes: 66aebce7 ("hugetlb: fix race condition in hugetlb_fault()")
      Signed-off-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Luiz Capitulino <lcapitulino@redhat.com>
      Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Cc: Steve Capper <steve.capper@linaro.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [lizf: Backported to 3.4:
       - adjust context
       - there's no huge_pte_lock, so lock mm->page_table_lock directly
       - the lable should be out_page_table_lock instead of out_ptl]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      027d8328
    • Mikulas Patocka's avatar
      cpufreq: speedstep-smi: enable interrupts when waiting · 73cee5a8
      Mikulas Patocka authored
      commit d4d4eda2 upstream.
      
      On Dell Latitude C600 laptop with Pentium 3 850MHz processor, the
      speedstep-smi driver sometimes loads and sometimes doesn't load with
      "change to state X failed" message.
      
      The hardware sometimes refuses to change frequency and in this case, we
      need to retry later. I found out that we need to enable interrupts while
      waiting. When we enable interrupts, the hardware blockage that prevents
      frequency transition resolves and the transition is possible. With
      disabled interrupts, the blockage doesn't resolve (no matter how long do
      we wait). The exact reasons for this hardware behavior are unknown.
      
      This patch enables interrupts in the function speedstep_set_state that can
      be called with disabled interrupts. However, this function is called with
      disabled interrupts only from speedstep_get_freqs, so it shouldn't cause
      any problem.
      
      Signed-off-by: Mikulas Patocka <mpatocka@redhat.com
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      73cee5a8
    • Trond Myklebust's avatar
      NFSv4.1: Fix a kfree() of uninitialised pointers in decode_cb_sequence_args · 9c71f4c2
      Trond Myklebust authored
      commit d8ba1f97 upstream.
      
      If the call to decode_rc_list() fails due to a memory allocation error,
      then we need to truncate the array size to ensure that we only call
      kfree() on those pointer that were allocated.
      Reported-by: default avatarDavid Ramos <daramos@stanford.edu>
      Fixes: 4aece6a1 ("nfs41: cb_sequence xdr implementation")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      9c71f4c2
    • Jan Kara's avatar
      fsnotify: fix handling of renames in audit · c93fc893
      Jan Kara authored
      commit 6ee8e25f upstream.
      
      Commit e9fd702a ("audit: convert audit watches to use fsnotify
      instead of inotify") broke handling of renames in audit.  Audit code
      wants to update inode number of an inode corresponding to watched name
      in a directory.  When something gets renamed into a directory to a
      watched name, inotify previously passed moved inode to audit code
      however new fsnotify code passes directory inode where the change
      happened.  That confuses audit and it starts watching parent directory
      instead of a file in a directory.
      
      This can be observed for example by doing:
      
        cd /tmp
        touch foo bar
        auditctl -w /tmp/foo
        touch foo
        mv bar foo
        touch foo
      
      In audit log we see events like:
      
        type=CONFIG_CHANGE msg=audit(1423563584.155:90): auid=1000 ses=2 op="updated rules" path="/tmp/foo" key=(null) list=4 res=1
        ...
        type=PATH msg=audit(1423563584.155:91): item=2 name="bar" inode=1046884 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
        type=PATH msg=audit(1423563584.155:91): item=3 name="foo" inode=1046842 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
        type=PATH msg=audit(1423563584.155:91): item=4 name="foo" inode=1046884 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE
        ...
      
      and that's it - we see event for the first touch after creating the
      audit rule, we see events for rename but we don't see any event for the
      last touch.  However we start seeing events for unrelated stuff
      happening in /tmp.
      
      Fix the problem by passing moved inode as data in the FS_MOVED_FROM and
      FS_MOVED_TO events instead of the directory where the change happens.
      This doesn't introduce any new problems because noone besides
      audit_watch.c cares about the passed value:
      
        fs/notify/fanotify/fanotify.c cares only about FSNOTIFY_EVENT_PATH events.
        fs/notify/dnotify/dnotify.c doesn't care about passed 'data' value at all.
        fs/notify/inotify/inotify_fsnotify.c uses 'data' only for FSNOTIFY_EVENT_PATH.
        kernel/audit_tree.c doesn't care about passed 'data' at all.
        kernel/audit_watch.c expects moved inode as 'data'.
      
      Fixes: e9fd702a ("audit: convert audit watches to use fsnotify instead of inotify")
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Cc: Paul Moore <paul@paul-moore.com>
      Cc: Eric Paris <eparis@redhat.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>
      c93fc893
    • Dan Carpenter's avatar
      ALSA: off by one bug in snd_riptide_joystick_probe() · 26ea9e4d
      Dan Carpenter authored
      commit e4940626 upstream.
      
      The problem here is that we check:
      
      	if (dev >= SNDRV_CARDS)
      
      Then we increment "dev".
      
             if (!joystick_port[dev++])
      
      Then we use it as an offset into a array with SNDRV_CARDS elements.
      
      	if (!request_region(joystick_port[dev], 8, "Riptide gameport")) {
      
      This has 3 effects:
      1) If you use the module option to specify the joystick port then it has
         to be shifted one space over.
      2) The wrong error message will be printed on failure if you have over
         32 cards.
      3) Static checkers will correctly complain that are off by one.
      
      Fixes: db1005ec ('ALSA: riptide - Fix joystick resource handling')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      26ea9e4d
    • Daniel Borkmann's avatar
      rtnetlink: ifla_vf_policy: fix misuses of NLA_BINARY · 1f18b807
      Daniel Borkmann authored
      commit 364d5716 upstream.
      
      ifla_vf_policy[] is wrong in advertising its individual member types as
      NLA_BINARY since .type = NLA_BINARY in combination with .len declares the
      len member as *max* attribute length [0, len].
      
      The issue is that when do_setvfinfo() is being called to set up a VF
      through ndo handler, we could set corrupted data if the attribute length
      is less than the size of the related structure itself.
      
      The intent is exactly the opposite, namely to make sure to pass at least
      data of minimum size of len.
      
      Fixes: ebc08a6f ("rtnetlink: Add VF config code to rtnetlink")
      Cc: Mitch Williams <mitch.a.williams@intel.com>
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [lizf: Backported to 3.4: drop changes to IFLA_VF_RATE and IFLA_VF_LINK_STATE]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      1f18b807
    • Sergey Ryazanov's avatar
      ath5k: fix spontaneus AR5312 freezes · 328f3cf1
      Sergey Ryazanov authored
      commit 8bfae4f9 upstream.
      
      Sometimes while CPU have some load and ath5k doing the wireless
      interface reset the whole WiSoC completely freezes. Set of tests shows
      that using atomic delay function while we wait interface reset helps to
      avoid such freezes.
      
      The easiest way to reproduce this issue: create a station interface,
      start continous scan with wpa_supplicant and load CPU by something. Or
      just create multiple station interfaces and put them all in continous
      scan.
      
      This patch partially reverts the commit 1846ac3d ("ath5k: Use
      usleep_range where possible"), which replaces initial udelay()
      by usleep_range().
      
      I do not know actual source of this issue, but all looks like that HW
      freeze is caused by transaction on internal SoC bus, while wireless
      block is in reset state.
      
      Also I should note that I do not know how many chips are affected, but I
      did not see this issue with chips, other than AR5312.
      
      CC: Jiri Slaby <jirislaby@gmail.com>
      CC: Nick Kossifidis <mickflemm@gmail.com>
      CC: Luis R. Rodriguez <mcgrof@do-not-panic.com>
      Fixes: 1846ac3d ("ath5k: Use usleep_range where possible")
      Reported-by: default avatarChristophe Prevotaux <c.prevotaux@rural-networks.com>
      Tested-by: default avatarChristophe Prevotaux <c.prevotaux@rural-networks.com>
      Tested-by: default avatarEric Bree <ebree@nltinc.com>
      Signed-off-by: default avatarSergey Ryazanov <ryazanov.s.a@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      328f3cf1
    • Peter Hurley's avatar
      tty: Prevent untrappable signals from malicious program · 39343b59
      Peter Hurley authored
      commit 37480a05 upstream.
      
      Commit 26df6d13 ("tty: Add EXTPROC support for LINEMODE")
      allows a process which has opened a pty master to send _any_ signal
      to the process group of the pty slave. Although potentially
      exploitable by a malicious program running a setuid program on
      a pty slave, it's unknown if this exploit currently exists.
      
      Limit to signals actually used.
      
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Howard Chu <hyc@symas.com>
      Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      39343b59
    • Nicolas Pitre's avatar
      vt: provide notifications on selection changes · 68e9176b
      Nicolas Pitre authored
      commit 19e3ae6b upstream.
      
      The vcs device's poll/fasync support relies on the vt notifier to signal
      changes to the screen content.  Notifier invocations were missing for
      changes that comes through the selection interface though.  Fix that.
      
      Tested with BRLTTY 5.2.
      Signed-off-by: default avatarNicolas Pitre <nico@linaro.org>
      Cc: Dave Mielke <dave@mielke.cc>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      68e9176b
    • Alan Stern's avatar
      USB: fix use-after-free bug in usb_hcd_unlink_urb() · c415c7ab
      Alan Stern authored
      commit c9919790 upstream.
      
      The usb_hcd_unlink_urb() routine in hcd.c contains two possible
      use-after-free errors.  The dev_dbg() statement at the end of the
      routine dereferences urb and urb->dev even though both structures may
      have been deallocated.
      
      This patch fixes the problem by storing urb->dev in a local variable
      (avoiding the dereference of urb) and moving the dev_dbg() up before
      the usb_put_dev() call.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Tested-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      c415c7ab
    • Alan Stern's avatar
      USB: add flag for HCDs that can't receive wakeup requests (isp1760-hcd) · 019b694f
      Alan Stern authored
      commit 074f9dd5 upstream.
      
      Currently the USB stack assumes that all host controller drivers are
      capable of receiving wakeup requests from downstream devices.
      However, this isn't true for the isp1760-hcd driver, which means that
      it isn't safe to do a runtime suspend of any device attached to a
      root-hub port if the device requires wakeup.
      
      This patch adds a "cant_recv_wakeups" flag to the usb_hcd structure
      and sets the flag in isp1760-hcd.  The core is modified to prevent a
      direct child of the root hub from being put into runtime suspend with
      wakeup enabled if the flag is set.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Tested-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      [lizf: Backported to 3.4: adjust context]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      019b694f
    • Oliver Neukum's avatar
      cdc-acm: add sanity checks · a54c78b9
      Oliver Neukum authored
      commit 7e860a6e upstream.
      
      Check the special CDC headers for a plausible minimum length.
      Another big operating systems ignores such garbage.
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.de>
      Reviewed-by: default avatarAdam Lee <adam8157@gmail.com>
      Tested-by: default avatarAdam Lee <adam8157@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [lizf: Backported to 3.4: adjust context]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      a54c78b9
    • Chuck Lever's avatar
      xprtrdma: Free the pd if ib_query_qp() fails · b1302625
      Chuck Lever authored
      commit 5ae711a2 upstream.
      
      If ib_query_qp() fails or the memory registration mode isn't
      supported, don't leak the PD. An orphaned IB/core resource will
      cause IB module removal to hang.
      
      Fixes: bd7ed1d1 ("RPC/RDMA: check selected memory registration ...")
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Reviewed-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      [lizf: Backported to 3.4: only two goto statements need to be changed]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      b1302625
    • Dmitry Eremin-Solenikov's avatar
      ARM: 8284/1: sa1100: clear RCSR_SMR on resume · 16d67beb
      Dmitry Eremin-Solenikov authored
      commit e461894d upstream.
      
      StrongARM core uses RCSR SMR bit to tell to bootloader that it was reset
      by entering the sleep mode. After we have resumed, there is little point
      in having that bit enabled. Moreover, if this bit is set before reboot,
      the bootloader can become confused. Thus clear the SMR bit on resume
      just before clearing the scratchpad (resume address) register.
      Signed-off-by: default avatarDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      16d67beb
    • Ian Abbott's avatar
      staging: comedi: comedi_compat32.c: fix COMEDI_CMD copy back · d2848d64
      Ian Abbott authored
      commit 42b8ce6f upstream.
      
      `do_cmd_ioctl()` in "comedi_fops.c" handles the `COMEDI_CMD` ioctl.
      This returns `-EAGAIN` if it has copied a modified `struct comedi_cmd`
      back to user-space.  (This occurs when the low-level Comedi driver's
      `do_cmdtest()` handler returns non-zero to indicate a problem with the
      contents of the `struct comedi_cmd`, or when the `struct comedi_cmd` has
      the `CMDF_BOGUS` flag set.)
      
      `compat_cmd()` in "comedi_compat32.c" handles the 32-bit compatible
      version of the `COMEDI_CMD` ioctl.  Currently, it never copies a 32-bit
      compatible version of `struct comedi_cmd` back to user-space, which is
      at odds with the way the regular `COMEDI_CMD` ioctl is handled.  To fix
      it, change `compat_cmd()` to copy a 32-bit compatible version of the
      `struct comedi_cmd` back to user-space when the main ioctl handler
      returns `-EAGAIN`.
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Reviewed-by: default avatarH Hartley Sweeten <hsweeten@visionengravers.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      d2848d64
    • Lennart Sorensen's avatar
      USB: cp210x: add ID for RUGGEDCOM USB Serial Console · 71ff678d
      Lennart Sorensen authored
      commit a6f03312 upstream.
      
      Added the USB serial console device ID for Siemens Ruggedcom devices
      which have a USB port for their serial console.
      Signed-off-by: default avatarLen Sorensen <lsorense@csclub.uwaterloo.ca>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      71ff678d
    • Michel Dänzer's avatar
      PCI: Fix infinite loop with ROM image of size 0 · af6d6d92
      Michel Dänzer authored
      commit 16b036af upstream.
      
      If the image size would ever read as 0, pci_get_rom_size() could keep
      processing the same image over and over again.  Exit the loop if we ever
      read a length of zero.
      
      This fixes a soft lockup on boot when the radeon driver calls
      pci_get_rom_size() on an AMD Radeon R7 250X PCIe discrete graphics card.
      
      [bhelgaas: changelog, reference]
      Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386973Reported-by: default avatarFederico <federicotg@gmail.com>
      Signed-off-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      af6d6d92
    • David Hildenbrand's avatar
      KVM: s390: base hrtimer on a monotonic clock · 8de2a8d9
      David Hildenbrand authored
      commit 0ac96caf upstream.
      
      The hrtimer that handles the wait with enabled timer interrupts
      should not be disturbed by changes of the host time.
      
      This patch changes our hrtimer to be based on a monotonic clock.
      Signed-off-by: default avatarDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Acked-by: default avatarCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      [lizf: Backported to 3.4: adjust context]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      8de2a8d9
    • Andrey Ryabinin's avatar
      smack: fix possible use after frees in task_security() callers · 6b962632
      Andrey Ryabinin authored
      commit 6d1cff2a upstream.
      
      We hit use after free on dereferncing pointer to task_smack struct in
      smk_of_task() called from smack_task_to_inode().
      
      task_security() macro uses task_cred_xxx() to get pointer to the task_smack.
      task_cred_xxx() could be used only for non-pointer members of task's
      credentials. It cannot be used for pointer members since what they point
      to may disapper after dropping RCU read lock.
      
      Mainly task_security() used this way:
      	smk_of_task(task_security(p))
      
      Intead of this introduce function smk_of_task_struct() which
      takes task_struct as argument and returns pointer to smk_known struct
      and do this under RCU read lock.
      Bogus task_security() macro is not used anymore, so remove it.
      
      KASan's report for this:
      
      	AddressSanitizer: use after free in smack_task_to_inode+0x50/0x70 at addr c4635600
      	=============================================================================
      	BUG kmalloc-64 (Tainted: PO): kasan error
      	-----------------------------------------------------------------------------
      
      	Disabling lock debugging due to kernel taint
      	INFO: Allocated in new_task_smack+0x44/0xd8 age=39 cpu=0 pid=1866
      		kmem_cache_alloc_trace+0x88/0x1bc
      		new_task_smack+0x44/0xd8
      		smack_cred_prepare+0x48/0x21c
      		security_prepare_creds+0x44/0x4c
      		prepare_creds+0xdc/0x110
      		smack_setprocattr+0x104/0x150
      		security_setprocattr+0x4c/0x54
      		proc_pid_attr_write+0x12c/0x194
      		vfs_write+0x1b0/0x370
      		SyS_write+0x5c/0x94
      		ret_fast_syscall+0x0/0x48
      	INFO: Freed in smack_cred_free+0xc4/0xd0 age=27 cpu=0 pid=1564
      		kfree+0x270/0x290
      		smack_cred_free+0xc4/0xd0
      		security_cred_free+0x34/0x3c
      		put_cred_rcu+0x58/0xcc
      		rcu_process_callbacks+0x738/0x998
      		__do_softirq+0x264/0x4cc
      		do_softirq+0x94/0xf4
      		irq_exit+0xbc/0x120
      		handle_IRQ+0x104/0x134
      		gic_handle_irq+0x70/0xac
      		__irq_svc+0x44/0x78
      		_raw_spin_unlock+0x18/0x48
      		sync_inodes_sb+0x17c/0x1d8
      		sync_filesystem+0xac/0xfc
      		vdfs_file_fsync+0x90/0xc0
      		vfs_fsync_range+0x74/0x7c
      	INFO: Slab 0xd3b23f50 objects=32 used=31 fp=0xc4635600 flags=0x4080
      	INFO: Object 0xc4635600 @offset=5632 fp=0x  (null)
      
      	Bytes b4 c46355f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
      	Object c4635600: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      	Object c4635610: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      	Object c4635620: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      	Object c4635630: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  kkkkkkkkkkkkkkk.
      	Redzone c4635640: bb bb bb bb                                      ....
      	Padding c46356e8: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
      	Padding c46356f8: 5a 5a 5a 5a 5a 5a 5a 5a                          ZZZZZZZZ
      	CPU: 5 PID: 834 Comm: launchpad_prelo Tainted: PBO 3.10.30 #1
      	Backtrace:
      	[<c00233a4>] (dump_backtrace+0x0/0x158) from [<c0023dec>] (show_stack+0x20/0x24)
      	 r7:c4634010 r6:d3b23f50 r5:c4635600 r4:d1002140
      	[<c0023dcc>] (show_stack+0x0/0x24) from [<c06d6d7c>] (dump_stack+0x20/0x28)
      	[<c06d6d5c>] (dump_stack+0x0/0x28) from [<c01c1d50>] (print_trailer+0x124/0x144)
      	[<c01c1c2c>] (print_trailer+0x0/0x144) from [<c01c1e88>] (object_err+0x3c/0x44)
      	 r7:c4635600 r6:d1002140 r5:d3b23f50 r4:c4635600
      	[<c01c1e4c>] (object_err+0x0/0x44) from [<c01cac18>] (kasan_report_error+0x2b8/0x538)
      	 r6:d1002140 r5:d3b23f50 r4:c6429cf8 r3:c09e1aa7
      	[<c01ca960>] (kasan_report_error+0x0/0x538) from [<c01c9430>] (__asan_load4+0xd4/0xf8)
      	[<c01c935c>] (__asan_load4+0x0/0xf8) from [<c031e168>] (smack_task_to_inode+0x50/0x70)
      	 r5:c4635600 r4:ca9da000
      	[<c031e118>] (smack_task_to_inode+0x0/0x70) from [<c031af64>] (security_task_to_inode+0x3c/0x44)
      	 r5:cca25e80 r4:c0ba9780
      	[<c031af28>] (security_task_to_inode+0x0/0x44) from [<c023d614>] (pid_revalidate+0x124/0x178)
      	 r6:00000000 r5:cca25e80 r4:cbabe3c0 r3:00008124
      	[<c023d4f0>] (pid_revalidate+0x0/0x178) from [<c01db98c>] (lookup_fast+0x35c/0x43y4)
      	 r9:c6429efc r8:00000101 r7:c079d940 r6:c6429e90 r5:c6429ed8 r4:c83c4148
      	[<c01db630>] (lookup_fast+0x0/0x434) from [<c01deec8>] (do_last.isra.24+0x1c0/0x1108)
      	[<c01ded08>] (do_last.isra.24+0x0/0x1108) from [<c01dff04>] (path_openat.isra.25+0xf4/0x648)
      	[<c01dfe10>] (path_openat.isra.25+0x0/0x648) from [<c01e1458>] (do_filp_open+0x3c/0x88)
      	[<c01e141c>] (do_filp_open+0x0/0x88) from [<c01ccb28>] (do_sys_open+0xf0/0x198)
      	 r7:00000001 r6:c0ea2180 r5:0000000b r4:00000000
      	[<c01cca38>] (do_sys_open+0x0/0x198) from [<c01ccc00>] (SyS_open+0x30/0x34)
      	[<c01ccbd0>] (SyS_open+0x0/0x34) from [<c001db80>] (ret_fast_syscall+0x0/0x48)
      	Read of size 4 by thread T834:
      	Memory state around the buggy address:
      	 c4635380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      	 c4635400: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
      	 c4635480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      	 c4635500: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
      	 c4635580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      	>c4635600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      	           ^
      	 c4635680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      	 c4635700: 00 00 00 00 04 fc fc fc fc fc fc fc fc fc fc fc
      	 c4635780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      	 c4635800: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc
      	 c4635880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      	==================================================================
      Signed-off-by: default avatarAndrey Ryabinin <a.ryabinin@samsung.com>
      [lizf: Backported to 3.4:
       - smk_of_task() returns char* instead of smack_known *
       - replace task_security() with smk_of_task() with smk_of_task_struct()
         manually]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      6b962632
    • Dmitry Tunin's avatar
      Bluetooth: ath3k: Add support of AR3012 bluetooth 13d3:3423 device · de2a293c
      Dmitry Tunin authored
      commit 033efa92 upstream.
      
      Add support of 13d3:3423 device.
      
      BugLink: https://bugs.launchpad.net/bugs/1411193
      
      T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
      D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
      P: Vendor=13d3 ProdID=3423 Rev= 0.01
      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 avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      de2a293c
    • Matthew Wilcox's avatar
      axonram: Fix bug in direct_access · b24c9cfb
      Matthew Wilcox authored
      commit 91117a20 upstream.
      
      The 'pfn' returned by axonram was completely bogus, and has been since
      2008.
      Signed-off-by: default avatarMatthew Wilcox <matthew.r.wilcox@intel.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      b24c9cfb
    • Sebastian Andrzej Siewior's avatar
      usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN · aef29c35
      Sebastian Andrzej Siewior authored
      commit 5efd2ea8 upstream.
      
      the following error pops up during "testusb -a -t 10"
      | musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128,	f134e000/be842000 (bad dma)
      hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
      size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
      hcd_buffer_alloc() returning memory which is 32 bytes aligned and it
      might by identified by buffer_offset() as another buffer. This means the
      buffer which is on a 32 byte boundary will not get freed, instead it
      tries to free another buffer with the error message.
      
      This patch fixes the issue by creating the smallest DMA buffer with the
      size of ARCH_KMALLOC_MINALIGN (or 32 in case ARCH_KMALLOC_MINALIGN is
      smaller). This might be 32, 64 or even 128 bytes. The next three pools
      will have the size 128, 512 and 2048.
      In case the smallest pool is 128 bytes then we have only three pools
      instead of four (and zero the first entry in the array).
      The last pool size is always 2048 bytes which is the assumed PAGE_SIZE /
      2 of 4096. I doubt it makes sense to continue using PAGE_SIZE / 2 where
      we would end up with 8KiB buffer in case we have 16KiB pages.
      Instead I think it makes sense to have a common size(s) and extend them
      if there is need to.
      There is a BUILD_BUG_ON() now in case someone has a minalign of more than
      128 bytes.
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      aef29c35
    • Ricardo Ribalda Delgado's avatar
      PCI: Generate uppercase hex for modalias var in uevent · 3274eed4
      Ricardo Ribalda Delgado authored
      commit 145b3fe5 upstream.
      
      Some implementations of modprobe fail to load the driver for a PCI device
      automatically because the "interface" part of the modalias from the kernel
      is lowercase, and the modalias from file2alias is uppercase.
      
      The "interface" is the low-order byte of the Class Code, defined in PCI
      r3.0, Appendix D.  Most interface types defined in the spec do not use
      alpha characters, so they won't be affected.  For example, 00h, 01h, 10h,
      20h, etc. are unaffected.
      
      Print the "interface" byte of the Class Code in uppercase hex, as we
      already do for the Vendor ID, Device ID, Class, etc.
      
      Commit 89ec3dcf ("PCI: Generate uppercase hex for modalias interface
      class") fixed only half of the problem.  Some udev implementations rely on
      the uevent file and not the modalias file.
      
      Fixes: d1ded203 ("PCI: add MODALIAS to hotplug event for pci devices")
      Fixes: 89ec3dcf ("PCI: Generate uppercase hex for modalias interface class")
      Signed-off-by: default avatarRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [lizf: Backported to 3.4: adjust filename]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      3274eed4
    • Martin Vajnar's avatar
      hx4700: regulator: declare full constraints · 0d51bca9
      Martin Vajnar authored
      commit a52d2093 upstream.
      
      Since the removal of CONFIG_REGULATOR_DUMMY option, the touchscreen stopped
      working. This patch enables the "replacement" for REGULATOR_DUMMY and
      allows the touchscreen to work even though there is no regulator for "vcc".
      Signed-off-by: default avatarMartin Vajnar <martin.vajnar@gmail.com>
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      0d51bca9
    • Dmitry Eremin-Solenikov's avatar
      ARM: pxa: add regulator_has_full_constraints to spitz board file · 3df3cce4
      Dmitry Eremin-Solenikov authored
      commit baad2dc4 upstream.
      
      Add regulator_has_full_constraints() call to spitz board file to let
      regulator core know that we do not have any additional regulators left.
      This lets it substitute unprovided regulators with dummy ones.
      
      This fixes the following warnings that can be seen on spitz if
      regulators are enabled:
      
      ads7846 spi2.0: unable to get regulator: -517
      spi spi2.0: Driver ads7846 requests probe deferral
      Signed-off-by: default avatarDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Acked-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      [lizf: Backported to 3.4: adjust context]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      3df3cce4
    • Dmitry Eremin-Solenikov's avatar
      ARM: pxa: add regulator_has_full_constraints to poodle board file · 6c6b1b29
      Dmitry Eremin-Solenikov authored
      commit 9bc78f32 upstream.
      
      Add regulator_has_full_constraints() call to poodle board file to let
      regulator core know that we do not have any additional regulators left.
      This lets it substitute unprovided regulators with dummy ones.
      
      This fixes the following warnings that can be seen on poodle if
      regulators are enabled:
      
      ads7846 spi1.0: unable to get regulator: -517
      spi spi1.0: Driver ads7846 requests probe deferral
      wm8731 0-001b: Failed to get supply 'AVDD': -517
      wm8731 0-001b: Failed to request supplies: -517
      wm8731 0-001b: ASoC: failed to probe component -517
      Signed-off-by: default avatarDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Acked-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      6c6b1b29
    • Dmitry Eremin-Solenikov's avatar
      ARM: pxa: add regulator_has_full_constraints to corgi board file · 830f8836
      Dmitry Eremin-Solenikov authored
      commit 271e8017 upstream.
      
      Add regulator_has_full_constraints() call to corgi board file to let
      regulator core know that we do not have any additional regulators left.
      This lets it substitute unprovided regulators with dummy ones.
      
      This fixes the following warnings that can be seen on corgi if
      regulators are enabled:
      
      ads7846 spi1.0: unable to get regulator: -517
      spi spi1.0: Driver ads7846 requests probe deferral
      wm8731 0-001b: Failed to get supply 'AVDD': -517
      wm8731 0-001b: Failed to request supplies: -517
      wm8731 0-001b: ASoC: failed to probe component -517
      corgi-audio corgi-audio: ASoC: failed to instantiate card -517
      Signed-off-by: default avatarDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Acked-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      830f8836
  2. 14 Apr, 2015 12 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