13 May, 2010

7 commits


12 May, 2010

26 commits

  • Conflicts:
    Documentation/feature-removal-schedule.txt
    drivers/net/wireless/ath/ar9170/usb.c
    drivers/scsi/iscsi_tcp.c
    net/ipv4/ipmr.c

    David S. Miller
     
  • * 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
    hwmon: (applesmc) Correct sysfs fan error handling
    hwmon: (asc7621) Bug fixes

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

    * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    kprobes/x86: Fix removed int3 checking order
    perf: Fix static strings treated like dynamic ones

    Linus Torvalds
     
  • i915_error_object_create() is called from the timer interrupt and hence
    can corrupt the KM_USER0 slot. Use KM_IRQ0 instead.

    Reported-by: Jaswinder Singh Rajput
    Tested-by: Jaswinder Singh Rajput
    Acked-by: Chris Wilson
    Cc: Dave Airlie
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • The work queue has to be flushed after the device has been made
    inaccessible. The patch closes a window during which a work queue might
    remain active after the device is removed and would then lead to ACPI
    calls with undefined behavior.

    Signed-off-by: Oliver Neukum
    Acked-by: Eric Piel
    Acked-by: Pavel Machek
    Cc: Pavel Herrmann
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oliver Neukum
     
  • In case of aborting because we reach the maximum amount of memory which
    can be allocated to message queues per user (RLIMIT_MSGQUEUE), we would
    try to free the message area twice when bailing out: first by the error
    handling code itself, and then later when cleaning up the inode through
    delete_inode().

    Signed-off-by: André Goddard Rosa
    Cc: Alexey Dobriyan
    Cc: Al Viro
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    André Goddard Rosa
     
  • The current allocation does not include the memory required for blanking
    lines. So avoid memory corruption when multiple devices are using the DMA
    memory near each other.

    Signed-off-by: Michael Hennerich
    Signed-off-by: Mike Frysinger
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Hennerich
     
  • Some callers (in memcontrol.c) calls css_is_ancestor() without
    rcu_read_lock. Because css_is_ancestor() has to access RCU protected
    data, it should be under rcu_read_lock().

    This makes css_is_ancestor() itself does safe access to RCU protected
    area. (At least, "root" can have refcnt==0 if it's not an ancestor of
    "child". So, we need rcu_read_lock().)

    Signed-off-by: KAMEZAWA Hiroyuki
    Cc: "Paul E. McKenney"
    Cc: Daisuke Nishimura
    Cc: Balbir Singh
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KAMEZAWA Hiroyuki
     
  • Commit ad4ba375373937817404fd92239ef4cadbded23b ("memcg: css_id() must be
    called under rcu_read_lock()") modifies memcontol.c for fixing RCU check
    message. But Andrew Morton pointed out that the fix doesn't seems sane
    and it was just for hidining lockdep messages.

    This is a patch for do proper things. Checking again, all places,
    accessing without rcu_read_lock, that commit fixies was intentional....
    all callers of css_id() has reference count on it. So, it's not necessary
    to be under rcu_read_lock().

    Considering again, we can use rcu_dereference_check for css_id(). We know
    css->id is valid if css->refcnt > 0. (css->id never changes and freed
    after css->refcnt going to be 0.)

    This patch makes use of rcu_dereference_check() in css_id/depth and remove
    unnecessary rcu-read-lock added by the commit.

    Signed-off-by: KAMEZAWA Hiroyuki
    Cc: "Paul E. McKenney"
    Cc: Daisuke Nishimura
    Cc: Balbir Singh
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KAMEZAWA Hiroyuki
     
  • acct_exit_ns --> acct_file_reopen deletes timer without check timer
    execution on other CPUs. So acct_timeout() can change an unmapped memory.

    Signed-off-by: Vitaliy Gusev
    Cc: Pavel Emelyanov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vitaliy Gusev
     
  • Currently page_address_in_vma() compares vma->anon_vma and
    page_anon_vma(page) for parameter check, but in 2.6.34 a vma can have
    multiple anon_vmas with anon_vma_chain, so current check does not work.
    (For anonymous page shared by multiple processes, some verified (page,vma)
    pairs return -EFAULT wrongly.)

    We can go to checking all anon_vmas in the "same_vma" chain, but it needs
    to meet lock requirement. Instead, we can remove anon_vma check safely
    because page_address_in_vma() assumes that page and vma are already
    checked to belong to the identical process.

    Signed-off-by: Naoya Horiguchi
    Reviewed-by: Rik van Riel
    Cc: Andi Kleen
    Cc: Andrea Arcangeli
    Cc: Mel Gorman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Naoya Horiguchi
     
  • Ordinarily, application using hugetlbfs will create mappings with
    reserves. For shared mappings, these pages are reserved before mmap()
    returns success and for private mappings, the caller process is guaranteed
    and a child process that cannot get the pages gets killed with sigbus.

    An application that uses MAP_NORESERVE gets no reservations and mmap()
    will always succeed at the risk the page will not be available at fault
    time. This might be used for example on very large sparse mappings where
    the developer is confident the necessary huge pages exist to satisfy all
    faults even though the whole mapping cannot be backed by huge pages.
    Unfortunately, if an allocation does fail, VM_FAULT_OOM is returned to the
    fault handler which proceeds to trigger the OOM-killer. This is
    unhelpful.

    Even without hugetlbfs mounted, a user using mmap() can trivially trigger
    the OOM-killer because VM_FAULT_OOM is returned (will provide example
    program if desired - it's a whopping 24 lines long). It could be
    considered a DOS available to an unprivileged user.

    This patch alters hugetlbfs to kill a process that uses MAP_NORESERVE
    where huge pages were not available with SIGBUS instead of triggering the
    OOM killer.

    This change affects hugetlb_cow() as well. I feel there is a failure case
    in there, but I didn't create one. It would need a fairly specific target
    in terms of the faulting application and the hugepage pool size. The
    hugetlb_no_page() path is much easier to hit but both might as well be
    closed.

    Signed-off-by: Mel Gorman
    Cc: Lee Schermerhorn
    Cc: David Rientjes
    Cc: Andi Kleen
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • Two "echo 0 > /sys/kernel/kexec_crash_size" OOPSes kernel. Also content
    of this file is invalid after first shrink to zero: it shows 1 instead of
    0.

    This scenario is unlikely to happen often (root privs, valid crashkernel=
    in cmdline, dump-capture kernel not loaded), I hit it only by chance.

    This patch fixes it.

    Signed-off-by: Vitaly Mayatskikh
    Cc: Cong Wang
    Cc: Neil Horman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vitaly Mayatskikh
     
  • In debugfs, printing of command response reports resp[2] twice: fix it to
    resp[3].

    Signed-off-by: Nicolas Ferre
    Haavard Skinnemoen
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nicolas Ferre
     
  • Disable data error interrupts while we are actually recording that there
    is not such errors. This will prevent, in some cases, the warning message
    printed at new request queuing (in atmci_start_request()).

    Signed-off-by: Nicolas Ferre
    Cc: Haavard Skinnemoen
    Cc:
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nicolas Ferre
     
  • The removing of an SD card in certain circumstances can lead to a kernel
    oops if we do not make sure that the "data" field of the host structure is
    valid. This patch adds a test in atmci_dma_cleanup() function and also
    calls atmci_stop_dma() before throwing away the reference to data.

    Signed-off-by: Nicolas Ferre
    Cc: Haavard Skinnemoen
    Cc:
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nicolas Ferre
     
  • Two parameters were swapped in the calls to atmci_init_slot().

    Signed-off-by: Nicolas Ferre
    Reported-by: Anders Grahn
    Cc: Haavard Skinnemoen
    Cc:
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nicolas Ferre
     
  • Originally, commit d899bf7b ("procfs: provide stack information for
    threads") attempted to introduce a new feature for showing where the
    threadstack was located and how many pages are being utilized by the
    stack.

    Commit c44972f1 ("procfs: disable per-task stack usage on NOMMU") was
    applied to fix the NO_MMU case.

    Commit 89240ba0 ("x86, fs: Fix x86 procfs stack information for threads on
    64-bit") was applied to fix a bug in ia32 executables being loaded.

    Commit 9ebd4eba7 ("procfs: fix /proc//stat stack pointer for kernel
    threads") was applied to fix a bug which had kernel threads printing a
    userland stack address.

    Commit 1306d603f ('proc: partially revert "procfs: provide stack
    information for threads"') was then applied to revert the stack pages
    being used to solve a significant performance regression.

    This patch nearly undoes the effect of all these patches.

    The reason for reverting these is it provides an unusable value in
    field 28. For x86_64, a fork will result in the task->stack_start
    value being updated to the current user top of stack and not the stack
    start address. This unpredictability of the stack_start value makes
    it worthless. That includes the intended use of showing how much stack
    space a thread has.

    Other architectures will get different values. As an example, ia64
    gets 0. The do_fork() and copy_process() functions appear to treat the
    stack_start and stack_size parameters as architecture specific.

    I only partially reverted c44972f1 ("procfs: disable per-task stack usage
    on NOMMU") . If I had completely reverted it, I would have had to change
    mm/Makefile only build pagewalk.o when CONFIG_PROC_PAGE_MONITOR is
    configured. Since I could not test the builds without significant effort,
    I decided to not change mm/Makefile.

    I only partially reverted 89240ba0 ("x86, fs: Fix x86 procfs stack
    information for threads on 64-bit") . I left the KSTK_ESP() change in
    place as that seemed worthwhile.

    Signed-off-by: Robin Holt
    Cc: Stefani Seibold
    Cc: KOSAKI Motohiro
    Cc: Michal Simek
    Cc: Ingo Molnar
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Robin Holt
     
  • The SIO chip contains 16 possible gpio lines, not 14. The schematic was
    not read carefully.

    Signed-off-by: Denis Turischev
    Cc: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Denis Turischev
     
  • dma_sync_single_range_for_cpu() and dma_sync_single_range_for_device() use
    a wrong address with a partial synchronization.

    Signed-off-by: FUJITA Tomonori
    Reviewed-by: Konrad Rzeszutek Wilk
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • Signed-off-by: Stephen Rothwell
    Signed-off-by: John W. Linville

    Stephen Rothwell
     
  • …wireless-next-2.6 into for-davem

    Conflicts:
    drivers/net/wireless/ath/ar9170/main.c

    John W. Linville
     
  • * 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
    drm/radeon: Fix 3 regressions - since buffer rework

    Linus Torvalds
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
    net: Fix FDDI and TR config checks in ipv4 arp and LLC.
    IPv4: unresolved multicast route cleanup
    mac80211: remove association work when processing deauth request
    ar9170: wait for asynchronous firmware loading
    ipv4: udp: fix short packet and bad checksum logging
    phy: Fix initialization in micrel driver.
    sctp: Fix a race between ICMP protocol unreachable and connect()
    veth: Dont kfree_skb() after dev_forward_skb()
    IPv6: fix IPV6_RECVERR handling of locally-generated errors
    net/gianfar: drop recycled skbs on MTU change
    iwlwifi: work around passive scan issue

    Linus Torvalds
     
  • Fix an occasional EIO returned by a call to vfs_unlink():

    [ 4868.465413] CacheFiles: I/O Error: Unlink failed
    [ 4868.465444] FS-Cache: Cache cachefiles stopped due to I/O error
    [ 4947.320011] CacheFiles: File cache on md3 unregistering
    [ 4947.320041] FS-Cache: Withdrawing cache "mycache"
    [ 5127.348683] FS-Cache: Cache "mycache" added (type cachefiles)
    [ 5127.348716] CacheFiles: File cache on md3 registered
    [ 7076.871081] CacheFiles: I/O Error: Unlink failed
    [ 7076.871130] FS-Cache: Cache cachefiles stopped due to I/O error
    [ 7116.780891] CacheFiles: File cache on md3 unregistering
    [ 7116.780937] FS-Cache: Withdrawing cache "mycache"
    [ 7296.813394] FS-Cache: Cache "mycache" added (type cachefiles)
    [ 7296.813432] CacheFiles: File cache on md3 registered

    What happens is this:

    (1) A cached NFS file is seen to have become out of date, so NFS retires the
    object and immediately acquires a new object with the same key.

    (2) Retirement of the old object is done asynchronously - so the lookup/create
    to generate the new object may be done first.

    This can be a problem as the old object and the new object must exist at
    the same point in the backing filesystem (i.e. they must have the same
    pathname).

    (3) The lookup for the new object sees that a backing file already exists,
    checks to see whether it is valid and sees that it isn't. It then deletes
    that file and creates a new one on disk.

    (4) The retirement phase for the old file is then performed. It tries to
    delete the dentry it has, but ext4_unlink() returns -EIO because the inode
    attached to that dentry no longer matches the inode number associated with
    the filename in the parent directory.

    The trace below shows this quite well.

    [md5sum] ==> __fscache_relinquish_cookie(ffff88002d12fb58{NFS.fh,ffff88002ce62100},1)
    [md5sum] ==> __fscache_acquire_cookie({NFS.server},{NFS.fh},ffff88002ce62100)

    NFS has retired the old cookie and asked for a new one.

    [kslowd] ==> fscache_object_state_machine({OBJ52,OBJECT_ACTIVE,24})
    [kslowd] OBJECT_DYING]
    [kslowd] ==> fscache_object_state_machine({OBJ53,OBJECT_INIT,0})
    [kslowd] OBJECT_LOOKING_UP]
    [kslowd] ==> fscache_object_state_machine({OBJ52,OBJECT_DYING,24})
    [kslowd] OBJECT_RECYCLING]

    The old object (OBJ52) is going through the terminal states to get rid of it,
    whilst the new object - (OBJ53) - is coming into being.

    [kslowd] ==> fscache_object_state_machine({OBJ53,OBJECT_LOOKING_UP,0})
    [kslowd] ==> cachefiles_walk_to_object({ffff88003029d8b8},OBJ53,@68,)
    [kslowd] lookup '@68'
    [kslowd] next -> ffff88002ce41bd0 positive
    [kslowd] advance
    [kslowd] lookup 'Es0g00og0_Nd_XCYe3BOzvXrsBLMlN6aw16M1htaA'
    [kslowd] next -> ffff8800369faac8 positive

    The new object has looked up the subdir in which the file would be in (getting
    dentry ffff88002ce41bd0) and then looked up the file itself (getting dentry
    ffff8800369faac8).

    [kslowd] validate 'Es0g00og0_Nd_XCYe3BOzvXrsBLMlN6aw16M1htaA'
    [kslowd] ==> cachefiles_bury_object(,'@68','Es0g00og0_Nd_XCYe3BOzvXrsBLMlN6aw16M1htaA')
    [kslowd] remove ffff8800369faac8 from ffff88002ce41bd0
    [kslowd] unlink stale object
    [kslowd] inode does not match i_ino.

    [kslowd] OBJECT_DEAD]
    [kslowd] ==> fscache_object_state_machine({OBJ53,OBJECT_AVAILABLE,0})
    [kslowd] OBJECT_ACTIVE]

    (Note that the above trace includes extra information beyond that produced by
    the upstream code).

    The fix is to note when an object that is being retired has had its object
    deleted preemptively by a replacement object that is being created, and to
    skip the second removal attempt in such a case.

    Reported-by: Greg M
    Reported-by: Mark Moseley
    Reported-by: Romain DEGEZ
    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds

    David Howells
     
  • Duplicate entries ended up acpisleep_dmi_table[] by accident.
    They don't hurt functionality, but they are ugly, so let's get
    rid of them.

    Cc: stable@kernel.org
    Signed-off-by: Alex Chiang
    Signed-off-by: Linus Torvalds

    Alex Chiang
     

11 May, 2010

7 commits

  • The current code will not remove the sysfs files for fan numbers three
    and up. Also, upon exit, fans one and two are removed regardless of
    their existence. This patch cleans up the sysfs error handling for
    the fans.

    Signed-off-by: Henrik Rydberg
    Signed-off-by: Jean Delvare

    Henrik Rydberg
     
  • * Allow fan minimum RPM to be set to zero without triggering alarms.
    * Fix voltage scaling arithmetic and correct scale factors.
    * Correct fan1-fan4 alarm bit shifts.
    * Correct register address for temp3_smoothing_enable.
    * Read the alarm registers with high priority.

    Signed-off-by: Ken Milmore
    Signed-off-by: Jean Delvare

    Ken Milmore
     
  • Fix kprobe/x86 to check removed int3 when failing to get kprobe
    from hlist. Since we have a time window between checking int3
    exists on probed address and getting kprobe on that address,
    we can have following scenario:

    -------
    CPU1 CPU2
    hit int3
    check int3 exists
    remove int3
    remove kprobe from hlist
    get kprobe from hlist
    no kprobe->OOPS!
    -------

    This patch moves int3 checking if there is no kprobe on that
    address for fixing this problem as follows:

    ------
    CPU1 CPU2
    hit int3
    remove int3
    remove kprobe from hlist
    get kprobe from hlist
    no kprobe->check int3 exists
    ->rollback&retry
    ------

    Signed-off-by: Masami Hiramatsu
    Acked-by: Ananth N Mavinakayanahalli
    Cc: systemtap
    Cc: DLE
    Cc: Dave Anderson
    Cc: Peter Zijlstra
    Cc: Mike Galbraith
    Cc: Paul Mackerras
    Cc: Arnaldo Carvalho de Melo
    Cc: Frederic Weisbecker
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Masami Hiramatsu
     
  • The raw_field_ptr() helper, used to retrieve the address of a field
    inside a trace event, treats every strings as if they were dynamic
    ie: having a secondary level of indirection to retrieve their
    contents.

    FIELD_IS_STRING doesn't mean FIELD_IS_DYNAMIC, we only need to
    compute the secondary dereference for the latter case.

    This fixes perf sched segfaults, bad cmdline report and may be
    some other bugs.

    Reported-by: Jason Baron
    Reported-by: Arnaldo Carvalho de Melo
    Signed-off-by: Frederic Weisbecker
    Cc: Ingo Molnar
    Cc: Peter Zijlstra
    Cc: Paul Mackerras
    Cc: Tom Zanussi

    Frederic Weisbecker
     
  • David S. Miller
     
  • David S. Miller
     
  • Commit b4fe945405e477cded91772b4fec854705443dd5 introduced 3 bugs,
    fix them:

    * Use the right command dword for second packet offset in
    RADEON_CNTL_PAINT/BITBLT_MULTI.
    * Don't leak memory if drm_buffer_copy_from_user() fails.
    * Don't call drm_buffer_unprocessed() unless drm_buffer_alloc() and
    drm_buffer_copy_from_user() have been called successfully first.

    Signed-off-by: Jean Delvare
    Cc: Pauli Nieminen
    Signed-off-by: Dave Airlie

    Jean Delvare