15 Mar, 2006

9 commits

  • Update the documentation for page migration.

    - Fix up bits and pieces in cpusets.txt

    - Rework text in vm/page-migration to be clearer and reflect the final
    version of page migration in 2.6.16. Mention Andi Kleen's numactl
    package that contains user space tools for page migration via
    libnuma. Add reference to numa_maps and to the manpage in numactl.

    - Add todo list for outstanding issues

    Signed-off-by: Christoph Lameter
    Acked-by: Paul Jackson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     
  • page migration currently simply retries a couple of times if try_to_unmap()
    fails without inspecting the return code.

    However, SWAP_FAIL indicates that the page is in a vma that has the
    VM_LOCKED flag set (if ignore_refs ==1). We can check for that return code
    and avoid retrying the migration.

    migrate_page_remove_references() now needs to return a reason why the
    failure occured. So switch migrate_page_remove_references to use -Exx
    style error messages.

    Signed-off-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     
  • It seems this patch got dropped (it was in addition to the `s390:
    improve response code handling in chsc_enable_facility()' patch).

    Acked-by: Cornelia Huck
    Cc: Martin Schwidefsky
    Cc: Heiko Carstens
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Greg Smith
     
  • * git://oss.sgi.com:8090/oss/git/rc-fixes:
    Fix a direct I/O locking issue revealed by the new mutex code.

    Linus Torvalds
     
  • Affects only XFS (i.e. DIO_OWN_LOCKING case) - currently it is
    not possible to get i_mutex locking correct when using DIO_OWN
    direct I/O locking in a filesystem due to indeterminism in the
    possible return code/lock/unlock combinations. This can cause
    a direct read to attempt a double i_mutex unlock inside XFS.

    We're now ensuring __blockdev_direct_IO always exits with the
    inode i_mutex (still) held for a direct reader.

    Tested with the three different locking modes (via direct block
    device access, ext3 and XFS) - both reading and writing; cannot
    find any regressions resulting from this change, and it clearly
    fixes the mutex_unlock warning originally reported here:
    http://marc.theaimsgroup.com/?l=linux-kernel&m=114189068126253&w=2

    Signed-off-by: Nathan Scott
    Acked-by: Christoph Hellwig

    Nathan Scott
     
  • This fixes a race where lsn could be cleared before taking the lock

    Signed-off-by: Dave Kleikamp
    Signed-off-by: Linus Torvalds

    Dave Kleikamp
     
  • * master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
    [SCSI] zfcp: fix device registration issues
    [SCSI] scsi_transport_fc: fix FC_HOST_NUM_ATTRS
    [SCSI] scsi: aha152x pcmcia driver needs spi transport
    [SCSI] zfcp: correctly set this_id for hosts
    [SCSI] Add Brownie to blacklist

    Linus Torvalds
     
  • lapic_shutdown() re-enables interrupts which is un-desirable for panic
    case, so use local_irq_save() and local_irq_restore() to keep the irqs
    disabled for kexec on panic case, and close a possible race window while
    kdump shutdown as shown in this stack trace

    -- BUG: spinlock lockup on CPU#1, bash/4396, c52781a0
    [] _raw_spin_lock+0xb7/0xd2
    [] _spin_lock+0x6/0x8
    [] scheduler_tick+0xe7/0x328
    [] update_process_times+0x51/0x5d
    [] smp_apic_timer_interrupt+0x4f/0x58
    [] lapic_shutdown+0x76/0x7e
    [] apic_timer_interrupt+0x1c/0x30
    [] lapic_shutdown+0x76/0x7e
    [] machine_crash_shutdown+0x83/0xaa
    [] crash_kexec+0xc1/0xe3
    [] _spin_lock+0x6/0x8
    [] crash_kexec+0xad/0xe3
    [] __handle_sysrq+0x84/0xfd
    [] write_sysrq_trigger+0x2c/0x35
    [] vfs_write+0xa2/0x13b
    [] sys_write+0x3b/0x64
    [] syscall_call+0x7/0xb

    Signed-off-by: Maneesh Soni
    Signed-off-by: Linus Torvalds

    Maneesh Soni
     
  • This reverts commit c33d4568aca9028a22857f94f5e0850012b6444b.

    Andrew Clayton and Hugh Dickins report that it's broken for them and
    causes strange page table and slab corruption, and spontaneous reboots.

    Let's get it right next time.

    Cc: Andrew Clayton
    Cc: Hugh Dickins
    Cc: Andi Kleen
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

14 Mar, 2006

11 commits

  • - Disable the EDAC sysfs code. The sysfs interface that EDAC presents to
    user space needs more thought, and is likely to change substantially.
    Therefore disable it for now so users don't start depending on it in its
    current form.

    - Disable the default behavior of calling panic() when an uncorrectible
    error is detected (since for now, there is no sysfs interface that allows
    the user to configure this behavior).

    Signed-off-by: David S. Peterson
    Cc: Greg KH
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Peterson
     
  • In theory, NLM specs assure us that the server will only reply LCK_GRANTED or
    LCK_DENIED_GRACE_PERIOD to our NLM_UNLOCK request.

    In practice, we should not assume this to be the case, and the code will
    currently Oops if we do.

    Signed-off-by: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Trond Myklebust
     
  • In rpc_wake_up() and rpc_wake_up_status(), it is possible for the call to
    __rpc_wake_up_task() to fail if another thread happens to be calling
    rpc_wake_up_task() on the same rpc_task.

    Problem noticed by Bruno Faccini.

    Signed-off-by: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Trond Myklebust
     
  • It turns out that nfs4_proc_get_root() may return raw NFSv4 errors instead of
    mapping them to kernel errors. Problem spotted by Neil Horman

    Signed-off-by: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Trond Myklebust
     
  • The Coverity checker spotted this possible NULL pointer dereference in
    rpc_new_client().

    Signed-off-by: Adrian Bunk
    Signed-off-by: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     
  • Based on an original patch by Mike O'Connor and Greg Banks of SGI.

    Mike states:

    A normal user can panic an NFS client and cause a local DoS with
    'judicious'(?) use of O_DIRECT. Any O_DIRECT write to an NFS file where the
    user buffer starts with a valid mapped page and contains an unmapped page,
    will crash in this way. I haven't followed the code, but O_DIRECT reads with
    similar user buffers will probably also crash albeit in different ways.

    Details: when nfs_get_user_pages() calls get_user_pages(), it detects and
    correctly handles get_user_pages() returning an error, which happens if the
    first page covered by the user buffer's address range is unmapped. However,
    if the first page is mapped but some subsequent page isn't, get_user_pages()
    will return a positive number which is less than the number of pages requested
    (this behaviour is sort of analagous to a short write() call and appears to be
    intentional). nfs_get_user_pages() doesn't detect this and hands off the
    array of pages (whose last few elements are random rubbish from the newly
    allocated array memory) to it's caller, whence they go to
    nfs_direct_write_seg(), which then totally ignores the nr_pages it's given,
    and calculates its own idea of how many pages are in the array from the user
    buffer length. Needless to say, when it comes to transmit those uninitialised
    page* pointers, we see a crash in the network stack.

    Signed-off-by: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Trond Myklebust
     
  • This patch fixes alternate signal stack corruption among cloned threads
    with CLONE_SIGHAND (and CLONE_VM) for linux-2.6.16-rc6.

    The value of alternate signal stack is currently inherited after a call of
    clone(... CLONE_SIGHAND | CLONE_VM). But if sigaltstack is set by a
    parent thread, and then if multiple cloned child threads (+ parent threads)
    call signal handler at the same time, some threads may be conflicted -
    because they share to use the same alternative signal stack region.
    Finally they get sigsegv. It's an undesirable race condition. Note that
    child threads created from NPTL pthread_create() also hit this conflict
    when the parent thread uses sigaltstack, without my patch.

    To fix this problem, this patch clears the child threads' sigaltstack
    information like exec(). This behavior follows the SUSv3 specification.
    In SUSv3, pthread_create() says "The alternate stack shall not be inherited
    (when new threads are initialized)". It means that sigaltstack should be
    cleared when sigaltstack memory space is shared by cloned threads with
    CLONE_SIGHAND.

    Note that I chose "if (clone_flags & CLONE_SIGHAND)" line because:
    - If clone_flags line is not existed, fork() does not inherit sigaltstack.
    - CLONE_VM is another choice, but vfork() does not inherit sigaltstack.
    - CLONE_SIGHAND implies CLONE_VM, and it looks suitable.
    - CLONE_THREAD is another candidate, and includes CLONE_SIGHAND + CLONE_VM,
    but this flag has a bit different semantics.
    I decided to use CLONE_SIGHAND.

    [ Changed to test for CLONE_VM && !CLONE_VFORK after discussion --Linus ]

    Signed-off-by: GOTO Masanori
    Cc: Roland McGrath
    Cc: Ingo Molnar
    Acked-by: Linus Torvalds
    Cc: Ulrich Drepper
    Cc: Jakub Jelinek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    GOTO Masanori
     
  • Report AC Power present in /proc/pmu/info if there is no battery.

    Signed-off-by: Olaf Hering
    Signed-off-by: Benjamin Herrenschmidt ,
    Cc: Paul Mackerras
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Benjamin Herrenschmidt
     
  • The behaviour of the all-in-one Video4Linux tuner driver apparently
    changed. It now wants to know the tv standard, otherwise it refuses to
    tune.

    Restore tuning functionality in my driver for the "Multimedia eXtension
    Board". The all-in-one tuner driver apparently changed its behaviour.

    Signed-off-by: Michael Hunold
    Cc: Mauro Carvalho Chehab
    Cc: Johannes Stezenbach
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Hunold
     
  • Fix a bug in the block-erase optimization for Dataflash; it was using block
    erase even for smaller segments that need page erase.

    That wouldn't matter for JFFS2, which never erases less than one block
    (sometimes several blocks), but for other callers it might.

    Signed-off-by: David Brownell
    Acked-by: David Woodhouse
    Acked-by: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Brownell
     
  • When we link a socket into the hash table, we need to make sure that we
    set the num/port fields so that it shows us with a non-zero port value
    in proc/netlink and on the wire. This code and comment is copied over
    from the IPv4 stack as is.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

13 Mar, 2006

11 commits


12 Mar, 2006

9 commits