23 Dec, 2010

13 commits

  • The taskstats structure is internally aligned on 8 byte boundaries but the
    layout of the aggregrate reply, with two NLA headers and the pid (each 4
    bytes), actually force the entire structure to be unaligned. This causes
    the kernel to issue unaligned access warnings on some architectures like
    ia64. Unfortunately, some software out there doesn't properly unroll the
    NLA packet and assumes that the start of the taskstats structure will
    always be 20 bytes from the start of the netlink payload. Aligning the
    start of the taskstats structure breaks this software, which we don't
    want. So, for now the alignment only happens on architectures that
    require it and those users will have to update to fixed versions of those
    packages. Space is reserved in the packet only when needed. This ifdef
    should be removed in several years e.g. 2012 once we can be confident
    that fixed versions are installed on most systems. We add the padding
    before the aggregate since the aggregate is already a defined type.

    Commit 85893120 ("delayacct: align to 8 byte boundary on 64-bit systems")
    previously addressed the alignment issues by padding out the pid field.
    This was supposed to be a compatible change but the circumstances
    described above mean that it wasn't. This patch backs out that change,
    since it was a hack, and introduces a new NULL attribute type to provide
    the padding. Padding the response with 4 bytes avoids allocating an
    aligned taskstats structure and copying it back. Since the structure
    weighs in at 328 bytes, it's too big to do it on the stack.

    Signed-off-by: Jeff Mahoney
    Reported-by: Brian Rogers
    Cc: Jeff Mahoney
    Cc: Guillaume Chazarain
    Cc: Balbir Singh
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Mahoney
     
  • The current packed struct implementation of unaligned access adds the
    packed attribute only to the field within the unaligned struct rather than
    to the struct as a whole. This is not sufficient to enforce proper
    behaviour on architectures with a default struct alignment of more than
    one byte.

    For example, the current implementation of __get_unaligned_cpu16 when
    compiled for arm with gcc -O1 -mstructure-size-boundary=32 assumes the
    struct is on a 4 byte boundary so performs the load of the 16bit packed
    field as if it were on a 4 byte boundary:

    __get_unaligned_cpu16:
    ldrh r0, [r0, #0]
    bx lr

    Moving the packed attribute to the struct rather than the field causes the
    proper unaligned access code to be generated:

    __get_unaligned_cpu16:
    ldrb r3, [r0, #0] @ zero_extendqisi2
    ldrb r0, [r0, #1] @ zero_extendqisi2
    orr r0, r3, r0, asl #8
    bx lr

    Signed-off-by: Will Newton
    Cc: Arnd Bergmann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Will Newton
     
  • When I added led_blink_set I had a typo: the return value of the hw
    offload is a regular error code that is zero when succesful, and in that
    case software emulation should not be used, rather than the other way
    around.

    Signed-off-by: Johannes Berg
    Cc: Richard Purdie
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Johannes Berg
     
  • Signed-off-by: Axel Lin
    Cc: Thomas Hellstrom
    Cc: Alan Hourihane
    Cc: Richard Purdie
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Axel Lin
     
  • GCC complained about update_mmu_cache() not being defined in migrate.c.
    Including seems to solve the problem.

    Signed-off-by: Michal Nazarewicz
    Signed-off-by: Kyungmin Park
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michal Nazarewicz
     
  • Match the buffer size to the amount of initialized values. Before, it was
    one too big and thus destroyed the neighbouring register causing the clock
    to run at false speeds.

    Reported-by: Andre van Rooyen
    Signed-off-by: Wolfram Sang
    Cc: Alessandro Zummo
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Wolfram Sang
     
  • Remove Jordan as the geode maintainer (he's not been interested in geode for
    some time), and add myself as the maintainer.

    Signed-off-by: Andres Salomon
    Cc: Daniel Drake
    Cc: Jordan Crouse
    Cc: Chris Ball
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andres Salomon
     
  • If GPIO request succeeds, but configuration fails, it should be released.

    Signed-off-by: Aaro Koskinen
    Acked-by: Eric Miao
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Aaro Koskinen
     
  • Using TASK_INTERRUPTIBLE in balance_dirty_pages() seems wrong. If it's
    going to do that then it must break out if signal_pending(), otherwise
    it's pretty much guaranteed to degenerate into a busywait loop. Plus we
    *do* want these processes to appear in D state and to contribute to load
    average.

    So it should be TASK_UNINTERRUPTIBLE. -- Andrew Morton

    Signed-off-by: Wu Fengguang
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Wu Fengguang
     
  • This happens when __logfs_create() tries to write a new inode to the disk
    which is full.

    __logfs_create() associates the transaction pointer with inode. During
    the logfs_write_inode() function call chain this transaction pointer is
    moved from inode to page->private using function move_inode_to_page
    (do_write_inode() -> inode_to_page() -> move_inode_to_page)

    When the write inode fails, the transaction is aborted and iput is called
    on the failed inode. During delete_inode the same transaction pointer
    associated with the page is getting used. Thus causing kernel BUG.

    The patch checks for error in write_inode() and restores the page->private
    to NULL.

    Addresses https://bugzilla.kernel.org/show_bug.cgi?id=20162

    Signed-off-by: Prasad Joshi
    Cc: Joern Engel
    Cc: Florian Mickler
    Cc: "Rafael J. Wysocki"
    Cc: Maciej Rutecki
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Prasad Joshi
     
  • do_logfs_journal_wl_pass() should use GFP_NOFS for memory allocation GC
    code calls btree_insert32 with GFP_KERNEL while holding a mutex
    super->s_write_mutex.

    The same mutex is used in address_space_operations->writepage(), and a
    call to writepage() could be triggered as a result of memory allocation
    in btree_insert32, causing a deadlock.

    Addresses https://bugzilla.kernel.org/show_bug.cgi?id=20342

    Signed-off-by: Prasad Joshi
    Cc: Joern Engel
    Cc: Florian Mickler
    Cc: "Rafael J. Wysocki"
    Cc: Maciej Rutecki
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Prasad Joshi
     
  • When correlating ftrace results with /proc/vmstat, I noticed that the
    reporting scripts value for "pages scanned" differed significantly. Both
    values were "right" depending on how you look at it.

    The difference is due to vmstat only counting scanning of the inactive
    list towards pages scanned. The analysis script for the tracepoint counts
    active and inactive list yielding a far higher value than vmstat. The
    resulting scanning/reclaim ratio looks much worse. The tracepoint is ok
    but this patch updates the reporting script so that the report values for
    scanned are similar to vmstat.

    Signed-off-by: Mel Gorman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • del_page_from_lru_list() already called mem_cgroup_del_lru(). So we must
    not call it again. It adds unnecessary overhead.

    It was not a runtime bug because the TestClearPageCgroupAcctLRU() early in
    mem_cgroup_del_lru_list() will prevent any double-deletion, etc.

    Signed-off-by: Minchan Kim
    Acked-by: Balbir Singh
    Acked-by: KAMEZAWA Hiroyuki
    Acked-by: Mel Gorman
    Reviewed-by: Johannes Weiner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Minchan Kim
     

22 Dec, 2010

1 commit


21 Dec, 2010

13 commits


20 Dec, 2010

3 commits

  • Linus reported that the new warning introduced by commit f26f9aff6aaf
    "Sched: fix skip_clock_update optimization" triggers. The need_resched
    flag can be set by other CPUs asynchronously so this debug check is
    bogus - remove it.

    Reported-by: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Mike Galbraith
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Ingo Molnar
     
  • …nel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

    * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    x86-32: Make sure we can map all of lowmem if we need to
    x86, vt-d: Handle previous faults after enabling fault handling
    x86: Enable the intr-remap fault handling after local APIC setup
    x86, vt-d: Fix the vt-d fault handling irq migration in the x2apic mode
    x86, vt-d: Quirk for masking vtd spec errors to platform error handling logic
    x86, xsave: Use alloc_bootmem_align() instead of alloc_bootmem()
    bootmem: Add alloc_bootmem_align()
    x86, gcc-4.6: Use gcc -m options when building vdso
    x86: HPET: Chose a paranoid safe value for the ETIME check
    x86: io_apic: Avoid unused variable warning when CONFIG_GENERIC_PENDING_IRQ=n

    * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    perf: Fix off by one in perf_swevent_init()
    perf: Fix duplicate events with multiple-pmu vs software events
    ftrace: Have recordmcount honor endianness in fn_ELF_R_INFO
    scripts/tags.sh: Add magic for trace-events
    tracing: Fix panic when lseek() called on "trace" opened for writing

    Linus Torvalds
     
  • …l/git/tip/linux-2.6-tip

    * 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    sched: Fix the irqtime code for 32bit
    sched: Fix the irqtime code to deal with u64 wraps
    nohz: Fix get_next_timer_interrupt() vs cpu hotplug
    Sched: fix skip_clock_update optimization
    sched: Cure more NO_HZ load average woes

    Linus Torvalds
     

19 Dec, 2010

3 commits


18 Dec, 2010

7 commits

  • The current tile rt_sigreturn() syscall pattern uses the common idiom
    of loading up pt_regs with all the saved registers from the time of
    the signal, then anticipating the fact that we will clobber the ABI
    "return value" register (r0) as we return from the syscall by setting
    the rt_sigreturn return value to whatever random value was in the pt_regs
    for r0.

    However, this breaks in our 64-bit kernel when running "compat" tasks,
    since we always sign-extend the "return value" register to properly
    handle returned pointers that are in the upper 2GB of the 32-bit compat
    address space. Doing this to the sigreturn path then causes occasional
    random corruption of the 64-bit r0 register.

    Instead, we stop doing the crazy "load the return-value register"
    hack in sigreturn. We already have some sigreturn-specific assembly
    code that we use to pass the pt_regs pointer to C code. We extend that
    code to also set the link register to point to a spot a few instructions
    after the usual syscall return address so we don't clobber the saved r0.
    Now it no longer matters what the rt_sigreturn syscall returns, and the
    pt_regs structure can be cleanly and completely reloaded.

    Signed-off-by: Chris Metcalf

    Chris Metcalf
     
  • Previously we were just setting up the "tp" register in the
    new task as started by clone() in libc. However, this is not
    quite right, since in principle a signal might be delivered to
    the new task before it had its TLS set up. (Of course, this race
    window still exists for resetting the libc getpid() cached value
    in the new task, in principle. But in any case, we are now doing
    this exactly the way all other architectures do it.)

    This change is important for 2.6.37 since the tile glibc we will
    be submitting upstream will not set TLS in user space any more,
    so it will only work on a kernel that has this fix. It should
    also be taken for 2.6.36.x in the stable tree if possible.

    Signed-off-by: Chris Metcalf
    Cc: stable

    Chris Metcalf
     
  • The initial values of the registers 0x01 and 0x17 are taken from the sensor
    table at capture start and updated according to the flag PDN_INV.

    Their values are updated at each step of the capture initialization and
    memorized for reuse in capture stop.

    This patch also fixed automatically some bad hardcoded values of these
    registers.

    Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine
     
  • Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine
     
  • The flag PDN_INV indicates that the sensor pin S_PWR_DN has not the same
    value as other webcams with the same sensor. For now, only two webcams have
    been so detected: the Microsoft's VX1000 and VX3000.

    Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine
     
  • Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine
     
  • Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine