1. 09 May, 2012 1 commit
    • Tejun Heo's avatar
      percpu: pcpu_embed_first_chunk() should free unused parts after all allocs are complete · 42b64281
      Tejun Heo authored
      pcpu_embed_first_chunk() allocates memory for each node, copies percpu
      data and frees unused portions of it before proceeding to the next
      group.  This assumes that allocations for different nodes doesn't
      overlap; however, depending on memory topology, the bootmem allocator
      may end up allocating memory from a different node than the requested
      one which may overlap with the portion freed from one of the previous
      percpu areas.  This leads to percpu groups for different nodes
      overlapping which is a serious bug.
      
      This patch separates out copy & partial free from the allocation loop
      such that all allocations are complete before partial frees happen.
      
      This also fixes overlapping frees which could happen on allocation
      failure path - out_free_areas path frees whole groups but the groups
      could have portions freed at that point.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: stable@vger.kernel.org
      Reported-by: default avatar"Pavel V. Panteleev" <pp_84@mail.ru>
      Tested-by: default avatar"Pavel V. Panteleev" <pp_84@mail.ru>
      LKML-Reference: <E1SNhwY-0007ui-V7.pp_84-mail-ru@f220.mail.ru>
      42b64281
  2. 08 May, 2012 5 commits
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 789505b0
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "Two fixes from Intel, one a regression, one because I merged an early
        version of a fix.
      
        Also the nouveau revert of the i2c code that was tested on the list."
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm/nouveau/i2c: resume use of i2c-algo-bit, rather than custom stack
        drm/i915: Do no set Stencil Cache eviction LRA w/a on gen7+
        drm/i915: disable sdvo hotplug on i945g/gm
      789505b0
    • Linus Torvalds's avatar
      Merge tag 'stable/for-linus-3.4-rc6-tag' of... · 4ed6cede
      Linus Torvalds authored
      Merge tag 'stable/for-linus-3.4-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen
      
      Pull xen fixes from Konrad Rzeszutek Wilk:
       - fix to Kconfig to make it fit within 80 line characters,
       - two bootup fixes (AMD 8-core and with PCI BIOS),
       - cleanup code in a Xen PV fb driver,
       - and a crash fix when trying to see non-existent PTE's
      
      * tag 'stable/for-linus-3.4-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
        xen/Kconfig: fix Kconfig layout
        xen/pci: don't use PCI BIOS service for configuration space accesses
        xen/pte: Fix crashes when trying to see non-existent PGD/PMD/PUD/PTEs
        xen/apic: Return the APIC ID (and version) for CPU 0.
        drivers/video/xen-fbfront.c: add missing cleanup code
      4ed6cede
    • Linus Torvalds's avatar
      Merge branch 'for-3.4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu · e9b19cd4
      Linus Torvalds authored
      Pull two percpu fixes from Tejun Heo:
       "One adds missing KERN_CONT on split printk()s and the other makes
        the percpu allocator avoid using PMD_SIZE as atom_size on x86_32.
      
        Using PMD_SIZE led to vmalloc area exhaustion on certain
        configurations (x86_32 android) and the only cost of using PAGE_SIZE
        instead is static percpu area not being aligned to large page
        mapping."
      
      * 'for-3.4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu:
        percpu, x86: don't use PMD_SIZE as embedded atom_size on 32bit
        percpu: use KERN_CONT in pcpu_dump_alloc_info()
      e9b19cd4
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm · 301cdf5c
      Linus Torvalds authored
      Pull ARM fixes from Russell King:
       "This is mainly audit fixes, found by folks who happened to enable this
        feature and then found it broke their user applications."
      
      * 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
        ARM: 7414/1: SMP: prevent use of the console when using idmap_pgd
        ARM: 7412/1: audit: use only AUDIT_ARCH_ARM regardless of endianness
        ARM: 7411/1: audit: fix treatment of saved ip register during syscall tracing
        ARM: 7410/1: Add extra clobber registers for assembly in kernel_execve
      301cdf5c
    • Tejun Heo's avatar
      percpu, x86: don't use PMD_SIZE as embedded atom_size on 32bit · d5e28005
      Tejun Heo authored
      With the embed percpu first chunk allocator, x86 uses either PAGE_SIZE
      or PMD_SIZE for atom_size.  PMD_SIZE is used when CPU supports PSE so
      that percpu areas are aligned to PMD mappings and possibly allow using
      PMD mappings in vmalloc areas in the future.  Using larger atom_size
      doesn't waste actual memory; however, it does require larger vmalloc
      space allocation later on for !first chunks.
      
      With reasonably sized vmalloc area, PMD_SIZE shouldn't be a problem
      but x86_32 at this point is anything but reasonable in terms of
      address space and using larger atom_size reportedly leads to frequent
      percpu allocation failures on certain setups.
      
      As there is no reason to not use PMD_SIZE on x86_64 as vmalloc space
      is aplenty and most x86_64 configurations support PSE, fix the issue
      by always using PMD_SIZE on x86_64 and PAGE_SIZE on x86_32.
      
      v2: drop cpu_has_pse test and make x86_64 always use PMD_SIZE and
          x86_32 PAGE_SIZE as suggested by hpa.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarYanmin Zhang <yanmin.zhang@intel.com>
      Reported-by: default avatarShuoX Liu <shuox.liu@intel.com>
      Acked-by: default avatarH. Peter Anvin <hpa@zytor.com>
      LKML-Reference: <4F97BA98.6010001@intel.com>
      Cc: stable@vger.kernel.org
      d5e28005
  3. 07 May, 2012 10 commits
  4. 06 May, 2012 6 commits
    • Linus Torvalds's avatar
      Linux 3.4-rc6 · d48b97b4
      Linus Torvalds authored
      d48b97b4
    • Linus Torvalds's avatar
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 18b15fcd
      Linus Torvalds authored
      Pull x86 fixes form Peter Anvin
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        intel_mid_powerbtn: mark irq as IRQF_NO_SUSPEND
        arch/x86/platform/geode/net5501.c: change active_low to 0 for LED driver
        x86, relocs: Remove an unused variable
        asm-generic: Use __BITS_PER_LONG in statfs.h
        x86/amd: Re-enable CPU topology extensions in case BIOS has disabled it
      18b15fcd
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs · 271fd5d7
      Linus Torvalds authored
      Pull btrfs fixes from Chris Mason:
       "The big ones here are a memory leak we introduced in rc1, and a
        scheduling while atomic if the transid on disk doesn't match the
        transid we expected.  This happens for corrupt blocks, or out of date
        disks.
      
        It also fixes up the ioctl definition for our ioctl to resolve logical
        inode numbers.  The __u32 was a merging error and doesn't match what
        we ship in the progs."
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
        Btrfs: avoid sleeping in verify_parent_transid while atomic
        Btrfs: fix crash in scrub repair code when device is missing
        btrfs: Fix mismatching struct members in ioctl.h
        Btrfs: fix page leak when allocing extent buffers
        Btrfs: Add properly locking around add_root_to_dirty_list
      271fd5d7
    • Al Viro's avatar
      x86: fix broken TASK_SIZE for ia32_aout · ce7e5d2d
      Al Viro authored
      Setting TIF_IA32 in load_aout_binary() used to be enough; these days
      TASK_SIZE is controlled by TIF_ADDR32 and that one doesn't get set
      there.  Switch to use of set_personality_ia32()...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ce7e5d2d
    • Chris Mason's avatar
      Btrfs: avoid sleeping in verify_parent_transid while atomic · b9fab919
      Chris Mason authored
      verify_parent_transid needs to lock the extent range to make
      sure no IO is underway, and so it can safely clear the
      uptodate bits if our checks fail.
      
      But, a few callers are using it with spinlocks held.  Most
      of the time, the generation numbers are going to match, and
      we don't want to switch to a blocking lock just for the error
      case.  This adds an atomic flag to verify_parent_transid,
      and changes it to return EAGAIN if it needs to block to
      properly verifiy things.
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      b9fab919
    • Colin Cross's avatar
      ARM: 7414/1: SMP: prevent use of the console when using idmap_pgd · fde165b2
      Colin Cross authored
      Commit 4e8ee7de (ARM: SMP: use
      idmap_pgd for mapping MMU enable during secondary booting)
      switched secondary boot to use idmap_pgd, which is initialized
      during early_initcall, instead of a page table initialized during
      __cpu_up.  This causes idmap_pgd to contain the static mappings
      but be missing all dynamic mappings.
      
      If a console is registered that creates a dynamic mapping, the
      printk in secondary_start_kernel will trigger a data abort on
      the missing mapping before the exception handlers have been
      initialized, leading to a hang.  Initial boot is not affected
      because no consoles have been registered, and resume is usually
      not affected because the offending console is suspended.
      Onlining a cpu with hotplug triggers the problem.
      
      A workaround is to the printk in secondary_start_kernel until
      after the page tables have been switched back to init_mm.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarColin Cross <ccross@android.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      fde165b2
  5. 05 May, 2012 13 commits
  6. 04 May, 2012 5 commits
    • Linus Torvalds's avatar
      Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · f756beba
      Linus Torvalds authored
      Pull timer fix from Thomas Gleixner.
      
      * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        rtc: Fix possible null pointer dereference in rtc-mpc5121.c
      f756beba
    • Linus Torvalds's avatar
      Merge git://git.samba.org/sfrench/cifs-2.6 · c6de1687
      Linus Torvalds authored
      Pull CIFS fixes from Steve French.
      
      * git://git.samba.org/sfrench/cifs-2.6:
        fs/cifs: fix parsing of dfs referrals
        cifs: make sure we ignore the credentials= and cred= options
        [CIFS] Update cifs version to 1.78
        cifs - check S_AUTOMOUNT in revalidate
        cifs: add missing initialization of server->req_lock
        cifs: don't cap ra_pages at the same level as default_backing_dev_info
        CIFS: Fix indentation in cifs_show_options
      c6de1687
    • Dave Jones's avatar
      CPU frequency drivers MAINTAINERS update · a03a09b2
      Dave Jones authored
      Remove myself as cpufreq maintainer.
      x86 driver changes can go through the regular x86/ACPI trees.
      ARM driver changes through the ARM trees.
      cpufreq core changes are rare these days, and can just go to lkml/direct.
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a03a09b2
    • Linus Torvalds's avatar
      seqlock: add 'raw_seqcount_begin()' function · 4f988f15
      Linus Torvalds authored
      The normal read_seqcount_begin() function will wait for any current
      writers to exit their critical region by looping until the sequence
      count is even.
      
      That "wait for sequence count to stabilize" is the right thing to do if
      the read-locker will just retry the whole operation on contention: no
      point in doing a potentially expensive reader sequence if we know at the
      beginning that we'll just end up re-doing it all.
      
      HOWEVER.  Some users don't actually retry the operation, but instead
      will abort and do the operation with proper locking.  So the sequence
      count case may be the optimistic quick case, but in the presense of
      writers you may want to do full locking in order to guarantee forward
      progress.  The prime example of this would be the RCU name lookup.
      
      And in that case, you may well be better off without the "retry early",
      and are in a rush to instead get to the failure handling.  Thus this
      "raw" interface that just returns the sequence number without testing it
      - it just forces the low bit to zero so that read_seqcount_retry() will
      always fail such a "active concurrent writer" scenario.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4f988f15
    • Linus Torvalds's avatar
      Fix __read_seqcount_begin() to use ACCESS_ONCE for sequence value read · 2f624278
      Linus Torvalds authored
      We really need to use a ACCESS_ONCE() on the sequence value read in
      __read_seqcount_begin(), because otherwise the compiler might end up
      reloading the value in between the test and the return of it.  As a
      result, it might end up returning an odd value (which means that a write
      is in progress).
      
      If the reader is then fast enough that that odd value is still the
      current one when the read_seqcount_retry() is done, we might end up with
      a "successful" read sequence, even despite the concurrent write being
      active.
      
      In practice this probably never really happens - there just isn't
      anything else going on around the read of the sequence count, and the
      common case is that we end up having a read barrier immediately
      afterwards.
      
      So the code sequence in which gcc might decide to reaload from memory is
      small, and there's no reason to believe it would ever actually do the
      reload.  But if the compiler ever were to decide to do so, it would be
      incredibly annoying to debug.  Let's just make sure.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2f624278