1. 02 Mar, 2015 39 commits
    • Naoya Horiguchi's avatar
      mm/hugetlb: take page table lock in follow_huge_pmd() · 7b0f6722
      Naoya Horiguchi authored
      commit e66f17ff upstream.
      
      We have a race condition between move_pages() and freeing hugepages, where
      move_pages() calls follow_page(FOLL_GET) for hugepages internally and
      tries to get its refcount without preventing concurrent freeing.  This
      race crashes the kernel, so this patch fixes it by moving FOLL_GET code
      for hugepages into follow_huge_pmd() with taking the page table lock.
      
      This patch intentionally removes page==NULL check after pte_page.
      This is justified because pte_page() never returns NULL for any
      architectures or configurations.
      
      This patch changes the behavior of follow_huge_pmd() for tail pages and
      then tail pages can be pinned/returned.  So the caller must be changed to
      properly handle the returned tail pages.
      
      We could have a choice to add the similar locking to
      follow_huge_(addr|pud) for consistency, but it's not necessary because
      currently these functions don't support FOLL_GET flag, so let's leave it
      for future development.
      
      Here is the reproducer:
      
        $ cat movepages.c
        #include <stdio.h>
        #include <stdlib.h>
        #include <numaif.h>
      
        #define ADDR_INPUT      0x700000000000UL
        #define HPS             0x200000
        #define PS              0x1000
      
        int main(int argc, char *argv[]) {
                int i;
                int nr_hp = strtol(argv[1], NULL, 0);
                int nr_p  = nr_hp * HPS / PS;
                int ret;
                void **addrs;
                int *status;
                int *nodes;
                pid_t pid;
      
                pid = strtol(argv[2], NULL, 0);
                addrs  = malloc(sizeof(char *) * nr_p + 1);
                status = malloc(sizeof(char *) * nr_p + 1);
                nodes  = malloc(sizeof(char *) * nr_p + 1);
      
                while (1) {
                        for (i = 0; i < nr_p; i++) {
                                addrs[i] = (void *)ADDR_INPUT + i * PS;
                                nodes[i] = 1;
                                status[i] = 0;
                        }
                        ret = numa_move_pages(pid, nr_p, addrs, nodes, status,
                                              MPOL_MF_MOVE_ALL);
                        if (ret == -1)
                                err("move_pages");
      
                        for (i = 0; i < nr_p; i++) {
                                addrs[i] = (void *)ADDR_INPUT + i * PS;
                                nodes[i] = 0;
                                status[i] = 0;
                        }
                        ret = numa_move_pages(pid, nr_p, addrs, nodes, status,
                                              MPOL_MF_MOVE_ALL);
                        if (ret == -1)
                                err("move_pages");
                }
                return 0;
        }
      
        $ cat hugepage.c
        #include <stdio.h>
        #include <sys/mman.h>
        #include <string.h>
      
        #define ADDR_INPUT      0x700000000000UL
        #define HPS             0x200000
      
        int main(int argc, char *argv[]) {
                int nr_hp = strtol(argv[1], NULL, 0);
                char *p;
      
                while (1) {
                        p = mmap((void *)ADDR_INPUT, nr_hp * HPS, PROT_READ | PROT_WRITE,
                                 MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB, -1, 0);
                        if (p != (void *)ADDR_INPUT) {
                                perror("mmap");
                                break;
                        }
                        memset(p, 0, nr_hp * HPS);
                        munmap(p, nr_hp * HPS);
                }
        }
      
        $ sysctl vm.nr_hugepages=40
        $ ./hugepage 10 &
        $ ./movepages 10 $(pgrep -f hugepage)
      
      Fixes: e632a938 ("mm: migrate: add hugepage migration code to move_pages()")
      Signed-off-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Reported-by: default avatarHugh 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>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7b0f6722
    • Naoya Horiguchi's avatar
      mm/hugetlb: pmd_huge() returns true for non-present hugepage · 24bb9d18
      Naoya Horiguchi authored
      commit cbef8478 upstream.
      
      Migrating hugepages and hwpoisoned hugepages are considered as non-present
      hugepages, and they are referenced via migration entries and hwpoison
      entries in their page table slots.
      
      This behavior causes race condition because pmd_huge() doesn't tell
      non-huge pages from migrating/hwpoisoned hugepages.  follow_page_mask() is
      one example where the kernel would call follow_page_pte() for such
      hugepage while this function is supposed to handle only normal pages.
      
      To avoid this, this patch makes pmd_huge() return true when pmd_none() is
      true *and* pmd_present() is false.  We don't have to worry about mixing up
      non-present pmd entry with normal pmd (pointing to leaf level pte entry)
      because pmd_present() is true in normal pmd.
      
      The same race condition could happen in (x86-specific) gup_pmd_range(),
      where this patch simply adds pmd_present() check instead of pmd_huge().
      This is because gup_pmd_range() is fast path.  If we have non-present
      hugepage in this function, we will go into gup_huge_pmd(), then return 0
      at flag mask check, and finally fall back to the slow path.
      
      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>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      24bb9d18
    • Mikulas Patocka's avatar
      cpufreq: speedstep-smi: enable interrupts when waiting · a3b6e7d4
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      a3b6e7d4
    • Trond Myklebust's avatar
      NFSv4.1: Fix a kfree() of uninitialised pointers in decode_cb_sequence_args · 237b8a43
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      237b8a43
    • Alex Deucher's avatar
      drm/radeon: only enable kv/kb dpm interrupts once v3 · dbdfc09c
      Alex Deucher authored
      commit 410af8d7 upstream.
      
      Enable at init and disable on fini. Workaround for hardware problems.
      
      v2 (chk): extend commit message
      v3: add new function
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: Christian König <christian.koenig@amd.com> (v2)
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      dbdfc09c
    • Christian König's avatar
      drm/radeon: workaround for CP HW bug on CIK · b7573839
      Christian König authored
      commit a9c73a0e upstream.
      
      Emit the EOP twice to avoid cache flushing problems.
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b7573839
    • Tony Battersby's avatar
      blk-mq: fix double-free in error path · c5caff73
      Tony Battersby authored
      commit 564e559f upstream.
      
      If the allocation of bt->bs fails, then bt->map can be freed twice, once
      in blk_mq_init_bitmap_tags() -> bt_alloc(), and once in
      blk_mq_init_bitmap_tags() -> bt_free().  Fix by setting the pointer to
      NULL after the first free.
      Signed-off-by: default avatarTony Battersby <tonyb@cybernetics.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c5caff73
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Do not wake up a splice waiter when page is not full · de8548cf
      Steven Rostedt (Red Hat) authored
      commit 1e0d6714 upstream.
      
      When an application connects to the ring buffer via splice, it can only
      read full pages. Splice does not work with partial pages. If there is
      not enough data to fill a page, the splice command will either block
      or return -EAGAIN (if set to nonblock).
      
      Code was added where if the page is not full, to just sleep again.
      The problem is, it will get woken up again on the next event. That
      is, when something is written into the ring buffer, if there is a waiter
      it will wake it up. The waiter would then check the buffer, see that
      it still does not have enough data to fill a page and go back to sleep.
      To make matters worse, when the waiter goes back to sleep, it could
      cause another event, which would wake it back up again to see it
      doesn't have enough data and sleep again. This produces a tremendous
      overhead and fills the ring buffer with noise.
      
      For example, recording sched_switch on an idle system for 10 seconds
      produces 25,350,475 events!!!
      
      Create another wait queue for those waiters wanting full pages.
      When an event is written, it only wakes up waiters if there's a full
      page of data. It does not wake up the waiter if the page is not yet
      full.
      
      After this change, recording sched_switch on an idle system for 10
      seconds produces only 800 events. Getting rid of 25,349,675 useless
      events (99.9969% of events!!), is something to take seriously.
      
      Cc: Rabin Vincent <rabin@rab.in>
      Fixes: e30f53aa "tracing: Do not busy wait in buffer splice"
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      de8548cf
    • Jan Kara's avatar
      fsnotify: fix handling of renames in audit · ac627c9e
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      ac627c9e
    • Vikram Mulukutla's avatar
      tracing: Fix unmapping loop in tracing_mark_write · 366475b9
      Vikram Mulukutla authored
      commit 7215853e upstream.
      
      Commit 6edb2a8a introduced
      an array map_pages that contains the addresses returned by
      kmap_atomic. However, when unmapping those pages, map_pages[0]
      is unmapped before map_pages[1], breaking the nesting requirement
      as specified in the documentation for kmap_atomic/kunmap_atomic.
      
      This was caught by the highmem debug code present in kunmap_atomic.
      Fix the loop to do the unmapping properly.
      
      Link: http://lkml.kernel.org/r/1418871056-6614-1-git-send-email-markivx@codeaurora.orgReviewed-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Reported-by: default avatarLime Yang <limey@codeaurora.org>
      Signed-off-by: default avatarVikram Mulukutla <markivx@codeaurora.org>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      366475b9
    • Konstantin Khlebnikov's avatar
      cfq-iosched: handle failure of cfq group allocation · 3b3c7a2a
      Konstantin Khlebnikov authored
      commit 69abaffe upstream.
      
      Cfq_lookup_create_cfqg() allocates struct blkcg_gq using GFP_ATOMIC.
      In cfq_find_alloc_queue() possible allocation failure is not handled.
      As a result kernel oopses on NULL pointer dereference when
      cfq_link_cfqq_cfqg() calls cfqg_get() for NULL pointer.
      
      Bug was introduced in v3.5 in commit cd1604fa ("blkcg: factor
      out blkio_group creation"). Prior to that commit cfq group lookup
      had returned pointer to root group as fallback.
      
      This patch handles this error using existing fallback oom_cfqq.
      Signed-off-by: default avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Fixes: cd1604fa ("blkcg: factor out blkio_group creation")
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3b3c7a2a
    • Shobhit Kumar's avatar
      drm/i915: Correct the IOSF Dev_FN field for IOSF transfers · 70fd9b70
      Shobhit Kumar authored
      commit d180d2bb upstream.
      
      As per the specififcation, the SB_DevFn is the PCI_DEVFN of the target
      device and not the source. So PCI_DEVFN(2,0) is not correct. Further the
      port ID should be enough to identify devices unless they are MFD. The
      SB_DevFn was intended to remove ambiguity in case of these MFD devices.
      
      For non MFD devices the recommendation for the target device IP was to
      ignore these fields, but not all of them followed the recommendation.
      Some like CCK ignore these fields and hence PCI_DEVFN(2, 0) works and so
      does PCI_DEVFN(0, 0) as it works for DPIO. The issue came to light because
      of GPIONC which was not getting programmed correctly with PCI_DEVFN(2, 0).
      It turned out that this did not follow the recommendation and expected 0
      in this field.
      
      In general the recommendation is to use SB_DevFn as PCI_DEVFN(0, 0) for
      all devices except target PCI devices.
      Signed-off-by: default avatarShobhit Kumar <shobhit.kumar@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      70fd9b70
    • David Hildenbrand's avatar
      KVM: s390: floating irqs: fix user triggerable endless loop · f823f3b3
      David Hildenbrand authored
      commit 8e2207cd upstream.
      
      If a vm with no VCPUs is created, the injection of a floating irq
      leads to an endless loop in the kernel.
      
      Let's skip the search for a destination VCPU for a floating irq if no
      VCPUs were created.
      Reviewed-by: default avatarDominik Dingel <dingel@linux.vnet.ibm.com>
      Reviewed-by: default avatarCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: default avatarDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f823f3b3
    • Hans de Goede's avatar
      ACPI / video: Add disable_native_backlight quirk for Samsung 510R · 3be0cd3f
      Hans de Goede authored
      commit e77a1635 upstream.
      
      Backlight control through the native intel interface does not work properly
      on the Samsung 510R, where as using the acpi_video interface does work, add
      a quirk for this.
      
      Link: https://bugzilla.redhat.com/show_bug.cgi?id=1186097Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3be0cd3f
    • Hans de Goede's avatar
      ACPI / video: Add disable_native_backlight quirk for Samsung 730U3E/740U3E · 53d8495e
      Hans de Goede authored
      commit 3295d730 upstream.
      
      The Samsung 730U3E/740U3E has integrated ATI Radeon graphics, and backlight
      control does not work properly when using the native interfaces.
      
      Link: https://bugzilla.redhat.com/show_bug.cgi?id=1094948Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      53d8495e
    • Hans de Goede's avatar
      ACPI / video: Add disable_native_backlight quirk for Dell XPS15 L521X · 7461b84a
      Hans de Goede authored
      commit 6a3ef10b upstream.
      
      The L521X variant of the Dell XPS15 has integrated nvidia graphics, and
      backlight control does not work properly when using the native interfaces.
      
      Link: https://bugzilla.redhat.com/show_bug.cgi?id=1163574Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7461b84a
    • Aaron Lu's avatar
      ACPI / video: Add some Samsung models to disable_native_backlight list · 134dcb36
      Aaron Lu authored
      commit 7d0b9349 upstream.
      
      Several Samsung laptop models (SAMSUNG 870Z5E/880Z5E/680Z5E and
      SAMSUNG 370R4E/370R4V/370R5E/3570RE/370R5V) do not have a working
      native backlight control interface so restore their acpi_videoX
      interface.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=84221
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=84651
      For SAMSUNG 870Z5E/880Z5E/680Z5E:
      Reported-and-tested-by: default avatarBrent Saner <brent.saner@gmail.com>
      Reported-by: default avatarVitaliy Filippov <vitalif@yourcmc.ru>
      Reported-by: default avatarLaszlo KREKACS <laszlo.krekacs.list@gmail.com>
      For SAMSUNG 370R4E/370R4V/370R5E/3570RE/370R5V:
      Reported-by: default avatarVladimir Perepechin <vovochka13@gmail.com>
      Signed-off-by: default avatarAaron Lu <aaron.lu@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      134dcb36
    • Ross Lagerwall's avatar
      xen/manage: Fix USB interaction issues when resuming · be7a2a5d
      Ross Lagerwall authored
      commit 72978b2f upstream.
      
      Commit 61a734d3 ("xen/manage: Always freeze/thaw processes when
      suspend/resuming") ensured that userspace processes were always frozen
      before suspending to reduce interaction issues when resuming devices.
      However, freeze_processes() does not freeze kernel threads.  Freeze
      kernel threads as well to prevent deadlocks with the khubd thread when
      resuming devices.
      
      This is what native suspend and resume does.
      
      Example deadlock:
      [ 7279.648010]  [<ffffffff81446bde>] ? xen_poll_irq_timeout+0x3e/0x50
      [ 7279.648010]  [<ffffffff81448d60>] xen_poll_irq+0x10/0x20
      [ 7279.648010]  [<ffffffff81011723>] xen_lock_spinning+0xb3/0x120
      [ 7279.648010]  [<ffffffff810115d1>] __raw_callee_save_xen_lock_spinning+0x11/0x20
      [ 7279.648010]  [<ffffffff815620b6>] ? usb_control_msg+0xe6/0x120
      [ 7279.648010]  [<ffffffff81747e50>] ? _raw_spin_lock_irq+0x50/0x60
      [ 7279.648010]  [<ffffffff8174522c>] wait_for_completion+0xac/0x160
      [ 7279.648010]  [<ffffffff8109c520>] ? try_to_wake_up+0x2c0/0x2c0
      [ 7279.648010]  [<ffffffff814b60f2>] dpm_wait+0x32/0x40
      [ 7279.648010]  [<ffffffff814b6eb0>] device_resume+0x90/0x210
      [ 7279.648010]  [<ffffffff814b7d71>] dpm_resume+0x121/0x250
      [ 7279.648010]  [<ffffffff8144c570>] ? xenbus_dev_request_and_reply+0xc0/0xc0
      [ 7279.648010]  [<ffffffff814b80d5>] dpm_resume_end+0x15/0x30
      [ 7279.648010]  [<ffffffff81449fba>] do_suspend+0x10a/0x200
      [ 7279.648010]  [<ffffffff8144a2f0>] ? xen_pre_suspend+0x20/0x20
      [ 7279.648010]  [<ffffffff8144a1d0>] shutdown_handler+0x120/0x150
      [ 7279.648010]  [<ffffffff8144c60f>] xenwatch_thread+0x9f/0x160
      [ 7279.648010]  [<ffffffff810ac510>] ? finish_wait+0x80/0x80
      [ 7279.648010]  [<ffffffff8108d189>] kthread+0xc9/0xe0
      [ 7279.648010]  [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80
      [ 7279.648010]  [<ffffffff8175087c>] ret_from_fork+0x7c/0xb0
      [ 7279.648010]  [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80
      
      [ 7441.216287] INFO: task khubd:89 blocked for more than 120 seconds.
      [ 7441.219457]       Tainted: G            X 3.13.11-ckt12.kz #1
      [ 7441.222176] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 7441.225827] khubd           D ffff88003f433440     0    89      2 0x00000000
      [ 7441.229258]  ffff88003ceb9b98 0000000000000046 ffff88003ce83000 0000000000013440
      [ 7441.232959]  ffff88003ceb9fd8 0000000000013440 ffff88003cd13000 ffff88003ce83000
      [ 7441.236658]  0000000000000286 ffff88003d3e0000 ffff88003ceb9bd0 00000001001aa01e
      [ 7441.240415] Call Trace:
      [ 7441.241614]  [<ffffffff817442f9>] schedule+0x29/0x70
      [ 7441.243930]  [<ffffffff81743406>] schedule_timeout+0x166/0x2c0
      [ 7441.246681]  [<ffffffff81075b80>] ? call_timer_fn+0x110/0x110
      [ 7441.249339]  [<ffffffff8174357e>] schedule_timeout_uninterruptible+0x1e/0x20
      [ 7441.252644]  [<ffffffff81077710>] msleep+0x20/0x30
      [ 7441.254812]  [<ffffffff81555f00>] hub_port_reset+0xf0/0x580
      [ 7441.257400]  [<ffffffff81558465>] hub_port_init+0x75/0xb40
      [ 7441.259981]  [<ffffffff814bb3c9>] ? update_autosuspend+0x39/0x60
      [ 7441.262817]  [<ffffffff814bb4f0>] ? pm_runtime_set_autosuspend_delay+0x50/0xa0
      [ 7441.266212]  [<ffffffff8155a64a>] hub_thread+0x71a/0x1750
      [ 7441.268728]  [<ffffffff810ac510>] ? finish_wait+0x80/0x80
      [ 7441.271272]  [<ffffffff81559f30>] ? usb_port_resume+0x670/0x670
      [ 7441.274067]  [<ffffffff8108d189>] kthread+0xc9/0xe0
      [ 7441.276305]  [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80
      [ 7441.279131]  [<ffffffff8175087c>] ret_from_fork+0x7c/0xb0
      [ 7441.281659]  [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80
      Signed-off-by: default avatarRoss Lagerwall <ross.lagerwall@citrix.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      be7a2a5d
    • Takashi Iwai's avatar
      ALSA: hda - Set up GPIO for Toshiba Satellite S50D · ad889794
      Takashi Iwai authored
      commit 4227de2a upstream.
      
      Toshiba Satellite S50D laptop with an IDT codec uses the GPIO4 (0x10)
      as the master EAPD.
      
      Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=915858Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ad889794
    • Takashi Iwai's avatar
      ALSA: hda - Add the pin fixup for HP Envy TS bass speaker · a4ab0d80
      Takashi Iwai authored
      commit 8695a003 upstream.
      
      NID 0x10 seems corresponding to the bass speaker.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a4ab0d80
    • James Hogan's avatar
      KVM: MIPS: Don't leak FPU/DSP to guest · b4db76b6
      James Hogan authored
      commit f798217d upstream.
      
      The FPU and DSP are enabled via the CP0 Status CU1 and MX bits by
      kvm_mips_set_c0_status() on a guest exit, presumably in case there is
      active state that needs saving if pre-emption occurs. However neither of
      these bits are cleared again when returning to the guest.
      
      This effectively gives the guest access to the FPU/DSP hardware after
      the first guest exit even though it is not aware of its presence,
      allowing FP instructions in guest user code to intermittently actually
      execute instead of trapping into the guest OS for emulation. It will
      then read & manipulate the hardware FP registers which technically
      belong to the user process (e.g. QEMU), or are stale from another user
      process. It can also crash the guest OS by causing an FP exception, for
      which a guest exception handler won't have been registered.
      
      First lets save and disable the FPU (and MSA) state with lose_fpu(1)
      before entering the guest. This simplifies the problem, especially for
      when guest FPU/MSA support is added in the future, and prevents FR=1 FPU
      state being live when the FR bit gets cleared for the guest, which
      according to the architecture causes the contents of the FPU and vector
      registers to become UNPREDICTABLE.
      
      We can then safely remove the enabling of the FPU in
      kvm_mips_set_c0_status(), since there should never be any active FPU or
      MSA state to save at pre-emption, which should plug the FPU leak.
      
      DSP state is always live rather than being lazily restored, so for that
      it is simpler to just clear the MX bit again when re-entering the guest.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Sanjay Lal <sanjayl@kymasys.com>
      Cc: Gleb Natapov <gleb@kernel.org>
      Cc: kvm@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      [ luis: backported to 3.16: files rename:
        - locore.S -> kvm_locore.S
        - mips.c -> kvm_mips.c ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b4db76b6
    • Alexander Usyskin's avatar
      mei: me: release hw from reset only during the reset flow · f4d17408
      Alexander Usyskin authored
      commit 663b7ee9 upstream.
      
      We might enter the interrupt handler with hw_ready already set,
      but prior we actually started the reset flow.
      To soleve this we move the reset release from the interrupt handler
      to the HW start wait function which is part of the reset sequence.
      Signed-off-by: default avatarAlexander Usyskin <alexander.usyskin@intel.com>
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f4d17408
    • Alexander Usyskin's avatar
      mei: mask interrupt set bit on clean reset bit · f6106f83
      Alexander Usyskin authored
      commit 1ab1e79b upstream.
      
      We should mask interrupt set bit when writing back
      hcsr value in reset bit clean-up.
      
      This is refinement for
      mei: clean reset bit before reset
      commit b13a65efSigned-off-by: default avatarAlexander Usyskin <alexander.usyskin@intel.com>
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f6106f83
    • Malcolm Priestley's avatar
      [media] lmedm04: Fix usb_submit_urb BOGUS urb xfer, pipe 1 != type 3 in interrupt urb · a9c7abac
      Malcolm Priestley authored
      commit 15e1ce33 upstream.
      
      A quirk of some older firmwares that report endpoint pipe type as PIPE_BULK
      but the endpoint otheriwse functions as interrupt.
      
      Check if usb_endpoint_type is USB_ENDPOINT_XFER_BULK and set as usb_rcvbulkpipe.
      Signed-off-by: default avatarMalcolm Priestley <tvboxspy@gmail.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a9c7abac
    • Peng Tao's avatar
      nfs41: .init_read and .init_write can be called with valid pg_lseg · 6184a5e0
      Peng Tao authored
      commit cb5d04bc upstream.
      
      With pgio refactoring in v3.15, .init_read and .init_write can be
      called with valid pgio->pg_lseg. file layout was fixed at that time
      by commit c6194271 (pnfs: filelayout: support non page aligned
      layouts). But the generic helper still needs to be fixed.
      Signed-off-by: default avatarPeng Tao <tao.peng@primarydata.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6184a5e0
    • Matej Dubovy's avatar
      Bluetooth: btusb: Add support for Lite-On (04ca) Broadcom based, BCM43142 · 3d08b574
      Matej Dubovy authored
      commit 8f0c304c upstream.
      
      Please add support for sub BT chip on the combo card
      Broadcom 43142A0 (in Lenovo E145), 04ca:2007
      
      /sys/kernel/debug/usb/devices
      
      T:  Bus=05 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=04ca ProdID=2007 Rev= 1.12
      S:  Manufacturer=Broadcom Corp
      S:  Product=BCM43142A0
      S:  SerialNumber=28E347EC73BD
      C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=  0mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
      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=(none)
      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=(none)
      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=(none)
      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=(none)
      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=(none)
      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=(none)
      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)
      
      Firmware for 04ca:2007 can be extracted from the latest Lenovo E145
      Bluetooth driver for Windows (driver is however described as BCM20702
      but contains also firwmare for BCM43142).
      Search for BCM43142A0_001.001.011.0122.0153.hex within hex files, then
      it must be converted using hex2hcd utility. Rename file to
      BCM43142A0-04ca-2007.hcd, then move to /lib/firmware/brcm/.
      Signed-off-by: default avatarMatej Dubovy <matej.dubovy@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3d08b574
    • Viresh Kumar's avatar
      cpufreq: Set cpufreq_cpu_data to NULL before putting kobject · a71f2f60
      Viresh Kumar authored
      commit 6ffae8c0 upstream.
      
      In __cpufreq_remove_dev_finish(), per-cpu 'cpufreq_cpu_data' needs
      to be cleared before calling kobject_put(&policy->kobj) and under
      cpufreq_driver_lock. Otherwise, if someone else calls cpufreq_cpu_get()
      in parallel with it, they can obtain a non-NULL policy from that after
      kobject_put(&policy->kobj) was executed.
      
      Consider this case:
      
      Thread A				Thread B
      cpufreq_cpu_get()
        acquire cpufreq_driver_lock
        read-per-cpu cpufreq_cpu_data
      					kobject_put(&policy->kobj);
        kobject_get(&policy->kobj);
      					...
      					per_cpu(&cpufreq_cpu_data, cpu) = NULL
      
      And this will result in a warning like this one:
      
       ------------[ cut here ]------------
       WARNING: CPU: 0 PID: 4 at include/linux/kref.h:47
       kobject_get+0x41/0x50()
       Modules linked in: acpi_cpufreq(+) nfsd auth_rpcgss nfs_acl
       lockd grace sunrpc xfs libcrc32c sd_mod ixgbe igb mdio ahci hwmon
       ...
       Call Trace:
        [<ffffffff81661b14>] dump_stack+0x46/0x58
        [<ffffffff81072b61>] warn_slowpath_common+0x81/0xa0
        [<ffffffff81072c7a>] warn_slowpath_null+0x1a/0x20
        [<ffffffff812e16d1>] kobject_get+0x41/0x50
        [<ffffffff815262a5>] cpufreq_cpu_get+0x75/0xc0
        [<ffffffff81527c3e>] cpufreq_update_policy+0x2e/0x1f0
        [<ffffffff810b8cb2>] ? up+0x32/0x50
        [<ffffffff81381aa9>] ? acpi_ns_get_node+0xcb/0xf2
        [<ffffffff81381efd>] ? acpi_evaluate_object+0x22c/0x252
        [<ffffffff813824f6>] ? acpi_get_handle+0x95/0xc0
        [<ffffffff81360967>] ? acpi_has_method+0x25/0x40
        [<ffffffff81391e08>] acpi_processor_ppc_has_changed+0x77/0x82
        [<ffffffff81089566>] ? move_linked_works+0x66/0x90
        [<ffffffff8138e8ed>] acpi_processor_notify+0x58/0xe7
        [<ffffffff8137410c>] acpi_ev_notify_dispatch+0x44/0x5c
        [<ffffffff8135f293>] acpi_os_execute_deferred+0x15/0x22
        [<ffffffff8108c910>] process_one_work+0x160/0x410
        [<ffffffff8108d05b>] worker_thread+0x11b/0x520
        [<ffffffff8108cf40>] ? rescuer_thread+0x380/0x380
        [<ffffffff81092421>] kthread+0xe1/0x100
        [<ffffffff81092340>] ? kthread_create_on_node+0x1b0/0x1b0
        [<ffffffff81669ebc>] ret_from_fork+0x7c/0xb0
        [<ffffffff81092340>] ? kthread_create_on_node+0x1b0/0x1b0
       ---[ end trace 89e66eb9795efdf7 ]---
      
      The actual code flow is as follows:
      
       Thread A: Workqueue: kacpi_notify
      
       acpi_processor_notify()
         acpi_processor_ppc_has_changed()
               cpufreq_update_policy()
                 cpufreq_cpu_get()
                   kobject_get()
      
       Thread B: xenbus_thread()
      
       xenbus_thread()
         msg->u.watch.handle->callback()
           handle_vcpu_hotplug_event()
             vcpu_hotplug()
               cpu_down()
                 __cpu_notify(CPU_POST_DEAD..)
                   cpufreq_cpu_callback()
                     __cpufreq_remove_dev_finish()
                       cpufreq_policy_put_kobj()
                         kobject_put()
      
      cpufreq_cpu_get() gets the policy from per-cpu variable cpufreq_cpu_data
      under cpufreq_driver_lock, and once it gets a valid policy it expects it
      to not be freed until cpufreq_cpu_put() is called.
      
      But the race happens when another thread puts the kobject first and updates
      cpufreq_cpu_data before or later. And so the first thread gets a valid policy
      structure and before it does kobject_get() on it, the second one has already
      done kobject_put().
      
      Fix this by setting cpufreq_cpu_data to NULL before putting the kobject and that
      too under locks.
      Reported-by: default avatarEthan Zhao <ethan.zhao@oracle.com>
      Reported-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a71f2f60
    • Stefan Agner's avatar
      serial: fsl_lpuart: avoid new transfer while DMA is running · 27e53e7c
      Stefan Agner authored
      commit 5f1437f6 upstream.
      
      When the UART is in DMA receive mode (RDMAS set) and one character
      just arrived while another interrupt is handled (e.g. TX), the RDRF
      (receiver data register full flag) is set due to the water level of
      1. But since the DMA will take care of this character, there is no
      need to handle it by calling lpuart_prepare_rx. Handling it leads to
      adding the RX timeout timer twice:
      
      [   74.336698] Kernel BUG at 80053070 [verbose debug info unavailable]
      [   74.342999] Internal error: Oops - BUG: 0 [#1] ARM0:00.00 khungtaskd
      [   74.347817] Modules linked in:    0 S  0.0  0.0   0:00.00 writeback
      [   74.350926] CPU: 0 PID: 0 Comm: swapper Not tainted 3.19.0-rc3-00001-g39d78e2 #1788
      [   74.358617] Hardware name: Freescale Vybrid VF610 (Device Tree)t
      [   74.364563] task: 807a7678 ti: 8079c000 task.ti: 8079c000 kblockd
      [   74.370002] PC is at add_timer+0x24/0x28.0  0.0   0:00.09 kworker/u2:1
      [   74.373960] LR is at lpuart_int+0x15c/0x3d8
      [   74.378171] pc : [<80053070>]    lr : [<802e0d88>]    psr: a0010193
      [   74.378171] sp : 8079de10  ip : 8079de20  fp : 8079de1c
      [   74.389694] r10: 807d44c0  r9 : 8688c300  r8 : 00000013
      [   74.394943] r7 : 20010193  r6 : 00000000  r5 : 000000a0  r4 : 86997210
      [   74.401498] r3 : ffffa7da  r2 : 80817868  r1 : 86997210  r0 : 86997344
      [   74.408052] Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      [   74.415489] Control: 10c5387d  Table: 8611c059  DAC: 00000015
      [   74.421265] Process swapper (pid: 0, stack limit = 0x8079c230)
      ...
      
      Solve this by only execute the receiver path (lpuart_prepare_rx) if
      the DMA receive mode (RDMAS) is not set. Also, make sure the flag is
      cleared on initialization, in case it has been left set.
      
      This can be best reproduced using UART as a serial console, then
      running top while dd'ing data into the terminal.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      27e53e7c
    • Stefan Agner's avatar
      serial: fsl_lpuart: delete timer on shutdown · ac64d693
      Stefan Agner authored
      commit 4a8588a1 upstream.
      
      If the serial port gets closed while a RX transfer is in progress,
      the timer might fire after the serial port shutdown finished. This
      leads in a NULL pointer dereference:
      
      [    7.508324] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      [    7.516590] pgd = 86348000
      [    7.519445] [00000000] *pgd=86179831, *pte=00000000, *ppte=00000000
      [    7.526145] Internal error: Oops: 17 [#1] ARM
      [    7.530611] Modules linked in:
      [    7.533876] CPU: 0 PID: 123 Comm: systemd Not tainted 3.19.0-rc3-00004-g5b11ea7 #1778
      [    7.541827] Hardware name: Freescale Vybrid VF610 (Device Tree)
      [    7.547862] task: 861c3400 ti: 86ac8000 task.ti: 86ac8000
      [    7.553392] PC is at lpuart_timer_func+0x24/0xf8
      [    7.558127] LR is at lpuart_timer_func+0x20/0xf8
      [    7.562857] pc : [<802df99c>]    lr : [<802df998>]    psr: 600b0113
      [    7.562857] sp : 86ac9b90  ip : 86ac9b90  fp : 86ac9bbc
      [    7.574467] r10: 80817180  r9 : 80817b98  r8 : 80817998
      [    7.579803] r7 : 807acee0  r6 : 86989000  r5 : 00000100  r4 : 86997210
      [    7.586444] r3 : 86ac8000  r2 : 86ac9bc0  r1 : 86997210  r0 : 00000000
      [    7.593085] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      [    7.600341] Control: 10c5387d  Table: 86348059  DAC: 00000015
      [    7.606203] Process systemd (pid: 123, stack limit = 0x86ac8230)
      
      Setup the timer on UART startup which allows to delete the timer
      unconditionally on shutdown. This also saves the initialization
      on each transfer.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ac64d693
    • Peter Hurley's avatar
      tty: Prevent untrappable signals from malicious program · 0d8aa186
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      0d8aa186
    • Nicolas Pitre's avatar
      vt: provide notifications on selection changes · 2731f668
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      2731f668
    • Luciano Coelho's avatar
      iwlwifi: mvm: fix failure path when power_update fails in add_interface · 42b2ca93
      Luciano Coelho authored
      commit fd66fc1c upstream.
      
      When iwl_mvm_power_update_mac() is called, we have already added the
      mac context, so if this call fails we should remove the mac.
      
      Fixes: commit e5e7aa8e ('iwlwifi: mvm: refactor power code')
      Signed-off-by: default avatarLuciano Coelho <luciano.coelho@intel.com>
      Reviewed-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      42b2ca93
    • Emmanuel Grumbach's avatar
      iwlwifi: pcie: disable the SCD_BASE_ADDR when we resume from WoWLAN · 7863d63e
      Emmanuel Grumbach authored
      commit cd8f4384 upstream.
      
      The base address of the scheduler in the device's memory
      (SRAM) comes from two different sources. The periphery
      register and the alive notification from the firmware.
      We have a check in iwl_pcie_tx_start that ensures that
      they are the same.
      When we resume from WoWLAN, the firmware may have crashed
      for whatever reason. In that case, the whole device may be
      reset which means that the periphery register will hold a
      meaningless value. When we come to compare
      trans_pcie->scd_base_addr (which really holds the value we
      had when we loaded the WoWLAN firmware upon suspend) and
      the current value of the register, we don't see a match
      unsurprisingly.
      Trick the check to avoid a loud yet harmless WARN.
      Note that when the WoWLAN has crashed, we will see that
      in iwl_trans_pcie_d3_resume which will let the op_mode
      know. Once the op_mode is informed that the WowLAN firmware
      has crashed, it can't do much besides resetting the whole
      device.
      Reviewed-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7863d63e
    • Luciano Coelho's avatar
      iwlwifi: mvm: always use mac color zero · a19b04a5
      Luciano Coelho authored
      commit 5523d11c upstream.
      
      We don't really need to use different mac colors when adding mac
      contexts, because they're not used anywhere.  In fact, the firmware
      doesn't accept 255 as a valid color, so we get into a SYSASSERT 0x3401
      when we reach that.
      
      Remove the color increment to use always zero and avoid reaching 255.
      Signed-off-by: default avatarLuciano Coelho <luciano.coelho@intel.com>
      Reviewed-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a19b04a5
    • Alan Stern's avatar
      USB: fix use-after-free bug in usb_hcd_unlink_urb() · 1886b1ae
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      1886b1ae
    • Alan Stern's avatar
      USB: add flag for HCDs that can't receive wakeup requests (isp1760-hcd) · cca1efc9
      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>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      cca1efc9
    • Oliver Neukum's avatar
      cdc-acm: add sanity checks · 27e636e8
      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>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      27e636e8
    • Jeff Layton's avatar
      nfs: don't call blocking operations while !TASK_RUNNING · 574a940f
      Jeff Layton authored
      commit 6ffa30d3 upstream.
      
      Bruce reported seeing this warning pop when mounting using v4.1:
      
           ------------[ cut here ]------------
           WARNING: CPU: 1 PID: 1121 at kernel/sched/core.c:7300 __might_sleep+0xbd/0xd0()
          do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff810ff58f>] prepare_to_wait+0x2f/0x90
          Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc fscache ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer ppdev joydev snd virtio_console virtio_balloon pcspkr serio_raw parport_pc parport pvpanic floppy soundcore i2c_piix4 virtio_blk virtio_net qxl drm_kms_helper ttm drm virtio_pci virtio_ring ata_generic virtio pata_acpi
          CPU: 1 PID: 1121 Comm: nfsv4.1-svc Not tainted 3.19.0-rc4+ #25
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153950- 04/01/2014
           0000000000000000 000000004e5e3f73 ffff8800b998fb48 ffffffff8186ac78
           0000000000000000 ffff8800b998fba0 ffff8800b998fb88 ffffffff810ac9da
           ffff8800b998fb68 ffffffff81c923e7 00000000000004d9 0000000000000000
          Call Trace:
           [<ffffffff8186ac78>] dump_stack+0x4c/0x65
           [<ffffffff810ac9da>] warn_slowpath_common+0x8a/0xc0
           [<ffffffff810aca65>] warn_slowpath_fmt+0x55/0x70
           [<ffffffff810ff58f>] ? prepare_to_wait+0x2f/0x90
           [<ffffffff810ff58f>] ? prepare_to_wait+0x2f/0x90
           [<ffffffff810dd2ad>] __might_sleep+0xbd/0xd0
           [<ffffffff8124c973>] kmem_cache_alloc_trace+0x243/0x430
           [<ffffffff810d941e>] ? groups_alloc+0x3e/0x130
           [<ffffffff810d941e>] groups_alloc+0x3e/0x130
           [<ffffffffa0301b1e>] svcauth_unix_accept+0x16e/0x290 [sunrpc]
           [<ffffffffa0300571>] svc_authenticate+0xe1/0xf0 [sunrpc]
           [<ffffffffa02fc564>] svc_process_common+0x244/0x6a0 [sunrpc]
           [<ffffffffa02fd044>] bc_svc_process+0x1c4/0x260 [sunrpc]
           [<ffffffffa03d5478>] nfs41_callback_svc+0x128/0x1f0 [nfsv4]
           [<ffffffff810ff970>] ? wait_woken+0xc0/0xc0
           [<ffffffffa03d5350>] ? nfs4_callback_svc+0x60/0x60 [nfsv4]
           [<ffffffff810d45bf>] kthread+0x11f/0x140
           [<ffffffff810ea815>] ? local_clock+0x15/0x30
           [<ffffffff810d44a0>] ? kthread_create_on_node+0x250/0x250
           [<ffffffff81874bfc>] ret_from_fork+0x7c/0xb0
           [<ffffffff810d44a0>] ? kthread_create_on_node+0x250/0x250
          ---[ end trace 675220a11e30f4f2 ]---
      
      nfs41_callback_svc does most of its work while in TASK_INTERRUPTIBLE,
      which is just wrong. Fix that by finishing the wait immediately if we've
      found that the list has something on it.
      
      Also, we don't expect this kthread to accept signals, so we should be
      using a TASK_UNINTERRUPTIBLE sleep instead. That however, opens us up
      hung task warnings from the watchdog, so have the schedule_timeout
      wake up every 60s if there's no callback activity.
      Reported-by: default avatar"J. Bruce Fields" <bfields@fieldses.org>
      Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      574a940f
    • Antti Palosaari's avatar
      [media] si2168: define symbol rate limits · 987d1daa
      Antti Palosaari authored
      commit f1ecc5d1 upstream.
      
      w_scan complains about missing symbol rate limits:
      This dvb driver is *buggy*: the symbol rate limits are undefined - please report to linuxtv.org
      
      Chip supports 1 to 7.2 MSymbol/s on DVB-C.
      Signed-off-by: default avatarAntti Palosaari <crope@iki.fi>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      987d1daa
  2. 24 Feb, 2015 1 commit