1. 11 Nov, 2013 1 commit
  2. 06 Nov, 2013 5 commits
  3. 01 Nov, 2013 2 commits
  4. 31 Oct, 2013 5 commits
    • Linus Torvalds's avatar
      Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 52469b4f
      Linus Torvalds authored
      Pull NUMA balancing memory corruption fixes from Ingo Molnar:
       "So these fixes are definitely not something I'd like to sit on, but as
        I said to Mel at the KS the timing is quite tight, with Linus planning
        v3.12-final within a week.
      
        Fedora-19 is affected:
      
         comet:~> grep NUMA_BALANCING /boot/config-3.11.3-201.fc19.x86_64
      
         CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
         CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
         CONFIG_NUMA_BALANCING=y
      
        AFAICS Ubuntu will be affected as well, once it updates the kernel:
      
         hubble:~> grep NUMA_BALANCING /boot/config-3.8.0-32-generic
      
         CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
         CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
         CONFIG_NUMA_BALANCING=y
      
        These 6 commits are a minimalized set of cherry-picks needed to fix
        the memory corruption bugs.  All commits are fixes, except "mm: numa:
        Sanitize task_numa_fault() callsites" which is a cleanup that made two
        followup fixes simpler.
      
        I've done targeted testing with just this SHA1 to try to make sure
        there are no cherry-picking artifacts.  The original non-cherry-picked
        set of fixes were exposed to linux-next for a couple of weeks"
      
      * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        mm: Account for a THP NUMA hinting update as one PTE update
        mm: Close races between THP migration and PMD numa clearing
        mm: numa: Sanitize task_numa_fault() callsites
        mm: Prevent parallel splits during THP migration
        mm: Wait for THP migrations to complete during NUMA hinting faults
        mm: numa: Do not account for a hinting fault if we raced
      52469b4f
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input · 026f8f61
      Linus Torvalds authored
      Pull input updates from Dmitry Torokhov:
       "A bit later than I would want, but the changes are very minor - a few
        new device IDs for new hardware in existing drivers, fix for battery
        in Wacom devices not be considered system battery and cause emergency
        hibernations, and a couple of other bug fixes"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
        Input: ALPS - add support for model found on Dell XT2
        Input: wacom - add support for ISDv4 0x10E sensor
        Input: wacom - add support for ISDv4 0x10F sensor
        Input: wacom - export battery scope
        Input: cm109 - convert high volume dev_err() to dev_err_ratelimited()
        Input: move name/timer init to input_alloc_dev()
        Input: i8042 - i8042_flush fix for a full 8042 buffer
        Input: pxa27x_keypad - fix NULL pointer dereference
      026f8f61
    • Linus Torvalds's avatar
      Merge tag 'pm+acpi-3.12-late' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · e7647027
      Linus Torvalds authored
      Pull ACPI and power management fixes from Rafael J Wysocki:
       "Last-minute ACPI and power management fixes for 3.12
      
         - Revert epoll and select commits related to the freezer, introduced
           during the 3.11 cycle, that cause mysterious user space breakage to
           occur during resume from suspend to RAM for multiple users of
           32-bit x86 systems.  Material for 3.11.y stable kernels.
      
         - Revert a recent ACPI-based PCI hotplug (ACPIPHP) commit that was
           part of boot problem fixes for one machine, but turns out to cause
           issues with hotplug on Thunderbolt chains with multiple devices.
           It also turns out to be unnecessary after another fix in the same
           area that went in later.  From Mika Westerberg"
      
      * tag 'pm+acpi-3.12-late' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious notifies"
        Revert "select: use freezable blocking call"
        Revert "epoll: use freezable blocking call"
      e7647027
    • Yunkang Tang's avatar
      Input: ALPS - add support for model found on Dell XT2 · 5beea882
      Yunkang Tang authored
      This patch adds support for touchpad found on Dell XT2. It's a dual device
      with device ID: 73, 00, 14, that comply with "ALPS_PROTO_V2".
      Signed-off-by: default avatarYunkang Tang <yunkang.tang@cn.alps.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      5beea882
    • Dave Airlie's avatar
      Merge branch 'drm-fixes-3.12' of git://people.freedesktop.org/~agd5f/linux into drm-fixes · 74c85e13
      Dave Airlie authored
      Just a few small fixes for radeon (audio regression fix,
      stability fix, and an endian bug noticed by coverity).
      
      * 'drm-fixes-3.12' of git://people.freedesktop.org/~agd5f/linux:
        drm/radeon/dpm: fix incompatible casting on big endian
        drm/radeon: disable bapm on KB
        drm/radeon: use sw CTS/N values for audio on DCE4+
      74c85e13
  5. 30 Oct, 2013 22 commits
    • Linus Torvalds's avatar
      Merge branch 'akpm' (fixes from Andrew Morton) · 12aee278
      Linus Torvalds authored
      Merge three fixes from Andrew Morton.
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        memcg: use __this_cpu_sub() to dec stats to avoid incorrect subtrahend casting
        percpu: fix this_cpu_sub() subtrahend casting for unsigneds
        mm/pagewalk.c: fix walk_page_range() access of wrong PTEs
      12aee278
    • Greg Thelen's avatar
      memcg: use __this_cpu_sub() to dec stats to avoid incorrect subtrahend casting · 5e8cfc3c
      Greg Thelen authored
      As of commit 3ea67d06 ("memcg: add per cgroup writeback pages
      accounting") memcg counter errors are possible when moving charged
      memory to a different memcg.  Charge movement occurs when processing
      writes to memory.force_empty, moving tasks to a memcg with
      memcg.move_charge_at_immigrate=1, or memcg deletion.
      
      An example showing error after memory.force_empty:
      
        $ cd /sys/fs/cgroup/memory
        $ mkdir x
        $ rm /data/tmp/file
        $ (echo $BASHPID >> x/tasks && exec mmap_writer /data/tmp/file 1M) &
        [1] 13600
        $ grep ^mapped x/memory.stat
        mapped_file 1048576
        $ echo 13600 > tasks
        $ echo 1 > x/memory.force_empty
        $ grep ^mapped x/memory.stat
        mapped_file 4503599627370496
      
      mapped_file should end with 0.
        4503599627370496 == 0x10,0000,0000,0000 == 0x100,0000,0000 pages
        1048576          == 0x10,0000           == 0x100 pages
      
      This issue only affects the source memcg on 64 bit machines; the
      destination memcg counters are correct.  So the rmdir case is not too
      important because such counters are soon disappearing with the entire
      memcg.  But the memcg.force_empty and memory.move_charge_at_immigrate=1
      cases are larger problems as the bogus counters are visible for the
      (possibly long) remaining life of the source memcg.
      
      The problem is due to memcg use of __this_cpu_from(.., -nr_pages), which
      is subtly wrong because it subtracts the unsigned int nr_pages (either
      -1 or -512 for THP) from a signed long percpu counter.  When
      nr_pages=-1, -nr_pages=0xffffffff.  On 64 bit machines stat->count[idx]
      is signed 64 bit.  So memcg's attempt to simply decrement a count (e.g.
      from 1 to 0) boils down to:
      
        long count = 1
        unsigned int nr_pages = 1
        count += -nr_pages  /* -nr_pages == 0xffff,ffff */
        count is now 0x1,0000,0000 instead of 0
      
      The fix is to subtract the unsigned page count rather than adding its
      negation.  This only works once "percpu: fix this_cpu_sub() subtrahend
      casting for unsigneds" is applied to fix this_cpu_sub().
      Signed-off-by: default avatarGreg Thelen <gthelen@google.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5e8cfc3c
    • Greg Thelen's avatar
      percpu: fix this_cpu_sub() subtrahend casting for unsigneds · bd09d9a3
      Greg Thelen authored
      this_cpu_sub() is implemented as negation and addition.
      
      This patch casts the adjustment to the counter type before negation to
      sign extend the adjustment.  This helps in cases where the counter type
      is wider than an unsigned adjustment.  An alternative to this patch is
      to declare such operations unsupported, but it seemed useful to avoid
      surprises.
      
      This patch specifically helps the following example:
        unsigned int delta = 1
        preempt_disable()
        this_cpu_write(long_counter, 0)
        this_cpu_sub(long_counter, delta)
        preempt_enable()
      
      Before this change long_counter on a 64 bit machine ends with value
      0xffffffff, rather than 0xffffffffffffffff.  This is because
      this_cpu_sub(pcp, delta) boils down to this_cpu_add(pcp, -delta),
      which is basically:
        long_counter = 0 + 0xffffffff
      
      Also apply the same cast to:
        __this_cpu_sub()
        __this_cpu_sub_return()
        this_cpu_sub_return()
      
      All percpu_test.ko passes, especially the following cases which
      previously failed:
      
        l -= ui_one;
        __this_cpu_sub(long_counter, ui_one);
        CHECK(l, long_counter, -1);
      
        l -= ui_one;
        this_cpu_sub(long_counter, ui_one);
        CHECK(l, long_counter, -1);
        CHECK(l, long_counter, 0xffffffffffffffff);
      
        ul -= ui_one;
        __this_cpu_sub(ulong_counter, ui_one);
        CHECK(ul, ulong_counter, -1);
        CHECK(ul, ulong_counter, 0xffffffffffffffff);
      
        ul = this_cpu_sub_return(ulong_counter, ui_one);
        CHECK(ul, ulong_counter, 2);
      
        ul = __this_cpu_sub_return(ulong_counter, ui_one);
        CHECK(ul, ulong_counter, 1);
      Signed-off-by: default avatarGreg Thelen <gthelen@google.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bd09d9a3
    • Chen LinX's avatar
      mm/pagewalk.c: fix walk_page_range() access of wrong PTEs · 3017f079
      Chen LinX authored
      When walk_page_range walk a memory map's page tables, it'll skip
      VM_PFNMAP area, then variable 'next' will to assign to vma->vm_end, it
      maybe larger than 'end'.  In next loop, 'addr' will be larger than
      'next'.  Then in /proc/XXXX/pagemap file reading procedure, the 'addr'
      will growing forever in pagemap_pte_range, pte_to_pagemap_entry will
      access the wrong pte.
      
        BUG: Bad page map in process procrank  pte:8437526f pmd:785de067
        addr:9108d000 vm_flags:00200073 anon_vma:f0d99020 mapping:  (null) index:9108d
        CPU: 1 PID: 4974 Comm: procrank Tainted: G    B   W  O 3.10.1+ #1
        Call Trace:
          dump_stack+0x16/0x18
          print_bad_pte+0x114/0x1b0
          vm_normal_page+0x56/0x60
          pagemap_pte_range+0x17a/0x1d0
          walk_page_range+0x19e/0x2c0
          pagemap_read+0x16e/0x200
          vfs_read+0x84/0x150
          SyS_read+0x4a/0x80
          syscall_call+0x7/0xb
      Signed-off-by: default avatarLiu ShuoX <shuox.liu@intel.com>
      Signed-off-by: default avatarChen LinX <linx.z.chen@intel.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Reviewed-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: <stable@vger.kernel.org>	[3.10.x+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3017f079
    • Russell King's avatar
      mm: list_lru: fix almost infinite loop causing effective livelock · c56b097a
      Russell King authored
      I've seen a fair number of issues with kswapd and other processes
      appearing to get stuck in v3.12-rc.  Using sysrq-p many times seems to
      indicate that it gets stuck somewhere in list_lru_walk_node(), called
      from prune_icache_sb() and super_cache_scan().
      
      I never seem to be able to trigger a calltrace for functions above that
      point.
      
      So I decided to add the following to super_cache_scan():
      
          @@ -81,10 +81,14 @@ static unsigned long super_cache_scan(struct shrinker *shrink,
                  inodes = list_lru_count_node(&sb->s_inode_lru, sc->nid);
                  dentries = list_lru_count_node(&sb->s_dentry_lru, sc->nid);
                  total_objects = dentries + inodes + fs_objects + 1;
          +printk("%s:%u: %s: dentries %lu inodes %lu total %lu\n", current->comm, current->pid, __func__, dentries, inodes, total_objects);
      
                  /* proportion the scan between the caches */
                  dentries = mult_frac(sc->nr_to_scan, dentries, total_objects);
                  inodes = mult_frac(sc->nr_to_scan, inodes, total_objects);
          +printk("%s:%u: %s: dentries %lu inodes %lu\n", current->comm, current->pid, __func__, dentries, inodes);
          +BUG_ON(dentries == 0);
          +BUG_ON(inodes == 0);
      
                  /*
                   * prune the dcache first as the icache is pinned by it, then
          @@ -99,7 +103,7 @@ static unsigned long super_cache_scan(struct shrinker *shrink,
                          freed += sb->s_op->free_cached_objects(sb, fs_objects,
                                                                 sc->nid);
                  }
          -
          +printk("%s:%u: %s: dentries %lu inodes %lu freed %lu\n", current->comm, current->pid, __func__, dentries, inodes, freed);
                  drop_super(sb);
                  return freed;
           }
      
      and shortly thereafter, having applied some pressure, I got this:
      
          update-apt-xapi:1616: super_cache_scan: dentries 25632 inodes 2 total 25635
          update-apt-xapi:1616: super_cache_scan: dentries 1023 inodes 0
          ------------[ cut here ]------------
          Kernel BUG at c0101994 [verbose debug info unavailable]
          Internal error: Oops - BUG: 0 [#3] SMP ARM
          Modules linked in: fuse rfcomm bnep bluetooth hid_cypress
          CPU: 0 PID: 1616 Comm: update-apt-xapi Tainted: G      D      3.12.0-rc7+ #154
          task: daea1200 ti: c3bf8000 task.ti: c3bf8000
          PC is at super_cache_scan+0x1c0/0x278
          LR is at trace_hardirqs_on+0x14/0x18
          Process update-apt-xapi (pid: 1616, stack limit = 0xc3bf8240)
          ...
          Backtrace:
            (super_cache_scan) from [<c00cd69c>] (shrink_slab+0x254/0x4c8)
            (shrink_slab) from [<c00d09a0>] (try_to_free_pages+0x3a0/0x5e0)
            (try_to_free_pages) from [<c00c59cc>] (__alloc_pages_nodemask+0x5)
            (__alloc_pages_nodemask) from [<c00e07c0>] (__pte_alloc+0x2c/0x13)
            (__pte_alloc) from [<c00e3a70>] (handle_mm_fault+0x84c/0x914)
            (handle_mm_fault) from [<c001a4cc>] (do_page_fault+0x1f0/0x3bc)
            (do_page_fault) from [<c001a7b0>] (do_translation_fault+0xac/0xb8)
            (do_translation_fault) from [<c000840c>] (do_DataAbort+0x38/0xa0)
            (do_DataAbort) from [<c00133f8>] (__dabt_usr+0x38/0x40)
      
      Notice that we had a very low number of inodes, which were reduced to
      zero my mult_frac().
      
      Now, prune_icache_sb() calls list_lru_walk_node() passing that number of
      inodes (0) into that as the number of objects to scan:
      
          long prune_icache_sb(struct super_block *sb, unsigned long nr_to_scan,
                               int nid)
          {
                  LIST_HEAD(freeable);
                  long freed;
      
                  freed = list_lru_walk_node(&sb->s_inode_lru, nid, inode_lru_isolate,
                                                 &freeable, &nr_to_scan);
      
      which does:
      
          unsigned long
          list_lru_walk_node(struct list_lru *lru, int nid, list_lru_walk_cb isolate,
                             void *cb_arg, unsigned long *nr_to_walk)
          {
      
                  struct list_lru_node    *nlru = &lru->node[nid];
                  struct list_head *item, *n;
                  unsigned long isolated = 0;
      
                  spin_lock(&nlru->lock);
          restart:
                  list_for_each_safe(item, n, &nlru->list) {
                          enum lru_status ret;
      
                          /*
                           * decrement nr_to_walk first so that we don't livelock if we
                           * get stuck on large numbesr of LRU_RETRY items
                           */
                          if (--(*nr_to_walk) == 0)
                                  break;
      
      So, if *nr_to_walk was zero when this function was entered, that means
      we're wanting to operate on (~0UL)+1 objects - which might as well be
      infinite.
      
      Clearly this is not correct behaviour.  If we think about the behaviour
      of this function when *nr_to_walk is 1, then clearly it's wrong - we
      decrement first and then test for zero - which results in us doing
      nothing at all.  A post-decrement would give the desired behaviour -
      we'd try to walk one object and one object only if *nr_to_walk were one.
      
      It also gives the correct behaviour for zero - we exit at this point.
      
      Fixes: 5cedf721 ("list_lru: fix broken LRU_RETRY behaviour")
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: Dave Chinner <dchinner@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      [ Modified to make sure we never underflow the count: this function gets
        called in a loop, so the 0 -> ~0ul transition is dangerous  - Linus ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c56b097a
    • Linus Torvalds's avatar
      Merge tag 'tty-3.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty · ced5d6b5
      Linus Torvalds authored
      Pull serial fixes from Greg KH:
       "Here are 3 tiny fixes that are needed for 3.12-final for some serial
        drivers.
      
        One of them is a revert of a broken patch, and two others are fixes
        for reported bugs.  All of these have been in linux-next for a while,
        I forgot I had not sent them to you yet, my fault"
      
      (Actually, Greg, you _had_ sent two of the three, so this pulls in just
      one actual new fix)
      
      * tag 'tty-3.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
        tty/serial: at91: fix uart/usart selection for older products
      ced5d6b5
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · b8cab706
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "Mainly Intel regression fixes and quirks, along with a simple one
        liner to fix rendernodes ioctl access (off by default, but testers
        want to test it)"
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm: allow DRM_IOCTL_VERSION on render-nodes
        drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb
        drm/i915: No LVDS hardware on Intel D410PT and D425KT
        drm/i915/dp: workaround BIOS eDP bpp clamping issue
        drm/i915: Add HSW CRT output readout support
        drm/i915: Add support for pipe_bpp readout
      b8cab706
    • Linus Torvalds's avatar
      Merge tag 'sound-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · 182b4fd9
      Linus Torvalds authored
      Pull sound fixes from Takashi Iwai:
       "A few small HD-audio regression fixes, mostly for stable kernels, too"
      
      * tag 'sound-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
        ALSA: hda - Fix silent headphone on Thinkpads with AD1984A codec
        ALSA: hda - Add missing initial vmaster hook at build_controls callback
        ALSA: hda - Fix unbalanced runtime PM refcount after S3/S4
      182b4fd9
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 96d33b08
      Linus Torvalds authored
      Pull KVM fixes from Paolo Bonzini:
       "Fixes for the 3.12 debugfs problem - removing the duplicate directory
        name, and using a better the error code"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: use a more sensible error number when debugfs directory creation fails
        KVM: Fix modprobe failure for kvm_intel/kvm_amd
      96d33b08
    • Dan Carpenter's avatar
      Staging: sb105x: info leak in mp_get_count() · a8b33654
      Dan Carpenter authored
      The icount.reserved[] array isn't initialized so it leaks stack
      information to userspace.
      Reported-by: default avatarNico Golde <nico@ngolde.de>
      Reported-by: default avatarFabian Yamaguchi <fabs@goesec.de>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a8b33654
    • Dan Carpenter's avatar
      Staging: bcm: info leak in ioctl · 8d1e7225
      Dan Carpenter authored
      The DevInfo.u32Reserved[] array isn't initialized so it leaks kernel
      information to user space.
      Reported-by: default avatarNico Golde <nico@ngolde.de>
      Reported-by: default avatarFabian Yamaguchi <fabs@goesec.de>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8d1e7225
    • Dan Carpenter's avatar
      staging: wlags49_h2: buffer overflow setting station name · b5e2f339
      Dan Carpenter authored
      We need to check the length parameter before doing the memcpy().  I've
      actually changed it to strlcpy() as well so that it's NUL terminated.
      
      You need CAP_NET_ADMIN to trigger these so it's not the end of the
      world.
      Reported-by: default avatarNico Golde <nico@ngolde.de>
      Reported-by: default avatarFabian Yamaguchi <fabs@goesec.de>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b5e2f339
    • Dan Carpenter's avatar
      aacraid: missing capable() check in compat ioctl · f856567b
      Dan Carpenter authored
      In commit d496f94d ('[SCSI] aacraid: fix security weakness') we
      added a check on CAP_SYS_RAWIO to the ioctl.  The compat ioctls need the
      check as well.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f856567b
    • Dan Carpenter's avatar
      staging: ozwpan: prevent overflow in oz_cdev_write() · c2c65cd2
      Dan Carpenter authored
      We need to check "count" so we don't overflow the ei->data buffer.
      Reported-by: default avatarNico Golde <nico@ngolde.de>
      Reported-by: default avatarFabian Yamaguchi <fabs@goesec.de>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c2c65cd2
    • Dan Carpenter's avatar
      uml: check length in exitcode_proc_write() · 201f99f1
      Dan Carpenter authored
      We don't cap the size of buffer from the user so we could write past the
      end of the array here.  Only root can write to this file.
      Reported-by: default avatarNico Golde <nico@ngolde.de>
      Reported-by: default avatarFabian Yamaguchi <fabs@goesec.de>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      201f99f1
    • Mika Westerberg's avatar
      Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious notifies" · ab122590
      Mika Westerberg authored
      Commit 2dc41281 (ACPI / hotplug / PCI: Avoid doing too much for
      spurious notifies) changed the enable_slot() to check return value of
      pci_scan_slot() and if it is zero return early from the function. It
      means that there were no new devices in this particular slot.
      
      However, if a device appeared deeper in the hierarchy the code now
      ignores it causing things like Thunderbolt chaining fail to recognize
      new devices.
      
      The problem with Alex Williamson's machine was solved with commit
      a47d8c8e (ACPI / hotplug / PCI: Avoid parent bus rescans on spurious
      device checks) and hence we should be able to restore the original
      functionality that we always rescan on bus check notification.
      
      On a device check notification we still check what acpiphp_rescan_slot()
      returns and on zero bail out early.
      
      Fixes: 2dc41281 (ACPI / hotplug / PCI: Avoid doing too much for spurious notifies)
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ab122590
    • Rafael J. Wysocki's avatar
      Revert "select: use freezable blocking call" · 59612d18
      Rafael J. Wysocki authored
      This reverts commit 9745cdb3 (select: use freezable blocking call)
      that triggers problems during resume from suspend to RAM on Paul Bolle's
      32-bit x86 machines.  Paul says:
      
        Ever since I tried running (release candidates of) v3.11 on the two
        working i686s I still have lying around I ran into issues on resuming
        from suspend. Reverting 9745cdb3 (select: use freezable blocking
        call) resolves those issues.
      
        Resuming from suspend on i686 on (release candidates of) v3.11 and
        later triggers issues like:
      
        traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0 in libc-2.16.so[b731c000+1b0000]
      
        and
      
        traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0 error:0 in rtkit-daemon[8048000+d000]
      
        Once I hit the systemd error I can only get out of the mess that the
        system is at that point by power cycling it.
      
      Since we are reverting another freezer-related change causing similar
      problems to happen, this one should be reverted as well.
      
      References: https://lkml.org/lkml/2013/10/29/583Reported-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Fixes: 9745cdb3 (select: use freezable blocking call)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: 3.11+ <stable@vger.kernel.org> # 3.11+
      59612d18
    • Rafael J. Wysocki's avatar
      Revert "epoll: use freezable blocking call" · c511851d
      Rafael J. Wysocki authored
      This reverts commit 1c441e92 (epoll: use freezable blocking call)
      which is reported to cause user space memory corruption to happen
      after suspend to RAM.
      
      Since it appears to be extremely difficult to root cause this
      problem, it is best to revert the offending commit and try to address
      the original issue in a better way later.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=61781Reported-by: default avatarNatrio <natrio@list.ru>
      Reported-by: default avatarJeff Pohlmeyer <yetanothergeek@gmail.com>
      Bisected-by: default avatarLeo Wolf <jclw@ymail.com>
      Fixes: 1c441e92 (epoll: use freezable blocking call)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: 3.11+ <stable@vger.kernel.org> # 3.11+
      c511851d
    • Paolo Bonzini's avatar
      KVM: use a more sensible error number when debugfs directory creation fails · 0c8eb04a
      Paolo Bonzini authored
      I don't know if this was due to cut and paste, or somebody was really
      using a D20 to pick the error code for kvm_init_debugfs as suggested by
      Linus (EFAULT is 14, so the possibility cannot be entirely ruled out).
      
      In any case, this patch fixes it.
      Reported-by: default avatarTim Gardner <tim.gardner@canonical.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      0c8eb04a
    • Tim Gardner's avatar
      KVM: Fix modprobe failure for kvm_intel/kvm_amd · d780a312
      Tim Gardner authored
      The x86 specific kvm init creates a new conflicting
      debugfs directory which causes modprobe issues
      with kvm_intel and kvm_amd. For example,
      
      sudo modprobe kvm_amd
      modprobe: ERROR: could not insert 'kvm_amd': Bad address
      
      The simplest fix is to just rename the directory. The following
      KVM config options are set:
      
      CONFIG_KVM_GUEST=y
      CONFIG_KVM_DEBUG_FS=y
      CONFIG_HAVE_KVM=y
      CONFIG_HAVE_KVM_IRQCHIP=y
      CONFIG_HAVE_KVM_IRQ_ROUTING=y
      CONFIG_HAVE_KVM_EVENTFD=y
      CONFIG_KVM_APIC_ARCHITECTURE=y
      CONFIG_KVM_MMIO=y
      CONFIG_KVM_ASYNC_PF=y
      CONFIG_HAVE_KVM_MSI=y
      CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y
      CONFIG_KVM=m
      CONFIG_KVM_INTEL=m
      CONFIG_KVM_AMD=m
      CONFIG_KVM_DEVICE_ASSIGNMENT=y
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: default avatarTim Gardner <tim.gardner@canonical.com>
      [Change debugfs directory name. - Paolo]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      d780a312
    • David Herrmann's avatar
      drm: allow DRM_IOCTL_VERSION on render-nodes · 3d3b78c0
      David Herrmann authored
      DRM_IOCTL_VERSION is a reliable way to get the driver-name and version
      information. It's not related to the interface-version (SET_VERSION ioctl)
      so we can safely enable it on render-nodes.
      
      Note that gbm uses udev-BUSID to load the correct mesa driver. However,
      the VERSION ioctl should be the more reliable way to do this (in case we
      add new DRM-bus drivers which have no BUSID or similar).
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      3d3b78c0
    • Dave Airlie's avatar
      Merge tag 'drm-intel-fixes-2013-10-29' of... · 2f2632ff
      Dave Airlie authored
      Merge tag 'drm-intel-fixes-2013-10-29' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
      
      Regression and warn fixes for i915.
      
      * tag 'drm-intel-fixes-2013-10-29' of git://people.freedesktop.org/~danvet/drm-intel:
        drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb
        drm/i915: No LVDS hardware on Intel D410PT and D425KT
        drm/i915/dp: workaround BIOS eDP bpp clamping issue
        drm/i915: Add HSW CRT output readout support
        drm/i915: Add support for pipe_bpp readout
      2f2632ff
  6. 29 Oct, 2013 5 commits
    • Linus Torvalds's avatar
      Fix a few incorrectly checked [io_]remap_pfn_range() calls · 7314e613
      Linus Torvalds authored
      Nico Golde reports a few straggling uses of [io_]remap_pfn_range() that
      really should use the vm_iomap_memory() helper.  This trivially converts
      two of them to the helper, and comments about why the third one really
      needs to continue to use remap_pfn_range(), and adds the missing size
      check.
      Reported-by: default avatarNico Golde <nico@ngolde.de>
      Cc: stable@kernel.org
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org.
      7314e613
    • Linus Torvalds's avatar
      Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · f9ec2e6f
      Linus Torvalds authored
      Pull perf tooling fixes from Ingo Molnar:
       "This contains five tooling fixes:
      
         - fix a remaining mmap2 assumption which resulted in perf top output
           breakage
         - fix mmap ring-buffer processing bug that corrupts data
         - fix for a severe python scripting memory leak
         - fix broken (and user-visible) -g option handling
         - fix stdio output
      
        The diffstat size is larger than what we'd like to see this late :-/"
      
      * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        perf tools: Fixup mmap event consumption
        perf top: Split -G and --call-graph
        perf record: Split -g and --call-graph
        perf hists: Add color overhead for stdio output buffer
        perf tools: Fix up /proc/PID/maps parsing
        perf script python: Fix mem leak due to missing Py_DECREFs on dict entries
      f9ec2e6f
    • Linus Torvalds's avatar
      Kconfig: make KOBJECT_RELEASE debugging require timer debugging · 2a999aa0
      Linus Torvalds authored
      Without the timer debugging, the delayed kobject release will just
      result in undebuggable oopses if it triggers any latent bugs.  That
      doesn't actually help debugging at all.
      
      So make DEBUG_KOBJECT_RELEASE depend on DEBUG_OBJECTS_TIMERS to avoid
      having people enable one without the other.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2a999aa0
    • Daniel Vetter's avatar
      drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb · 1fbc0d78
      Daniel Vetter authored
      Originally I've thought that this is leftover hw state dirt from the
      BIOS. But after way too much helpless flailing around on my part I've
      noticed that the actual bug is when we change the state of an already
      active pipe.
      
      For example when we change the fdi lines from 2 to 3 without switching
      off outputs in-between we'll never see the crucial on->off transition
      in the ->modeset_global_resources hook the current logic relies on.
      
      Patch version 2 got this right by instead also checking whether the
      pipe is indeed active. But that in turn broke things when pipes have
      been turned off through dpms since the bifurcate enabling is done in
      the ->crtc_mode_set callback.
      
      To address this issues discussed with Ville in the patch review move
      the setting of the bifurcate bit into the ->crtc_enable hook. That way
      we won't wreak havoc with this state when userspace puts all other
      outputs into dpms off state. This also moves us forward with our
      overall goal to unify the modeset and dpms on paths (which we need to
      have to allow runtime pm in the dpms off state).
      
      Unfortunately this requires us to move the bifurcate helpers around a
      bit.
      
      Also update the commit message, I've misanalyzed the bug rather badly.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70507Tested-by: default avatarJan-Michael Brummer <jan.brummer@tabos.org>
      Cc: stable@vger.kernel.org
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      1fbc0d78
    • Ben Segall's avatar
      sched: Avoid throttle_cfs_rq() racing with period_timer stopping · f9f9ffc2
      Ben Segall authored
      throttle_cfs_rq() doesn't check to make sure that period_timer is running,
      and while update_curr/assign_cfs_runtime does, a concurrently running
      period_timer on another cpu could cancel itself between this cpu's
      update_curr and throttle_cfs_rq(). If there are no other cfs_rqs running
      in the tg to restart the timer, this causes the cfs_rq to be stranded
      forever.
      
      Fix this by calling __start_cfs_bandwidth() in throttle if the timer is
      inactive.
      
      (Also add some sched_debug lines for cfs_bandwidth.)
      
      Tested: make a run/sleep task in a cgroup, loop switching the cgroup
      between 1ms/100ms quota and unlimited, checking for timer_active=0 and
      throttled=1 as a failure. With the throttle_cfs_rq() change commented out
      this fails, with the full patch it passes.
      Signed-off-by: default avatarBen Segall <bsegall@google.com>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: pjt@google.com
      Link: http://lkml.kernel.org/r/20131016181632.22647.84174.stgit@sword-of-the-dawn.mtv.corp.google.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f9f9ffc2