04 Aug, 2009

1 commit


03 Aug, 2009

21 commits

  • * 'for-linus' of git://neil.brown.name/md:
    md: Use revalidate_disk to effect changes in size of device.
    md: allow raid5_quiesce to work properly when reshape is happening.
    md/raid5: set reshape_position correctly when reshape starts.
    md: Handle growth of v1.x metadata correctly.
    md: avoid array overflow with bad v1.x metadata
    md: when a level change reduces the number of devices, remove the excess.
    md: Push down data integrity code to personalities.
    md/raid6: release spare page at ->stop()

    Linus Torvalds
     
  • As revalidate_disk calls check_disk_size_change, it will cause
    any capacity change of a gendisk to be propagated to the blockdev
    inode. So use that instead of mucking about with locks and
    i_size_write.

    Also add a call to revalidate_disk in do_md_run and a few other places
    where the gendisk capacity is changed.

    Signed-off-by: NeilBrown

    NeilBrown
     
  • The ->quiesce method is not supposed to stop resync/recovery/reshape,
    just normal IO.
    But in raid5 we don't have a way to know which stripes are being
    used for normal IO and which for resync etc, so we need to wait for
    all stripes to be idle to be sure that all writes have completed.

    However reshape keeps at least some stripe busy for an extended period
    of time, so a call to raid5_quiesce can block for several seconds
    needlessly.
    So arrange for reshape etc to pause briefly while raid5_quiesce is
    trying to quiesce the array so that the active_stripes count can
    drop to zero.

    Signed-off-by: NeilBrown

    NeilBrown
     
  • As the internal reshape_progress counter is the main driver
    for reshape, the fact that reshape_position sometimes starts with the
    wrong value has minimal effect. It is visible in sysfs and that
    is all.

    Signed-off-by: NeilBrown

    NeilBrown
     
  • The v1.x metadata does not have a fixed size and can grow
    when devices are added.
    If it grows enough to require an extra sector of storage,
    we need to update the 'sb_size' to match.

    Without this, md can write out an incomplete superblock with a
    bad checksum, which will be rejected when trying to re-assemble
    the array.

    Cc: stable@kernel.org
    Signed-off-by: NeilBrown

    NeilBrown
     
  • We trust the 'desc_nr' field in v1.x metadata enough to use it
    as an index in an array. This isn't really safe.
    So range-check the value first.

    Signed-off-by: NeilBrown

    NeilBrown
     
  • When an array is changed from RAID6 to RAID5, fewer drives are
    needed. So any device that is made superfluous by the level
    conversion must be marked as not-active.
    For the RAID6->RAID5 conversion, this will be a drive which only
    has 'Q' blocks on it.

    Cc: stable@kernel.org
    Signed-off-by: NeilBrown

    NeilBrown
     
  • This patch replaces md_integrity_check() by two new public functions:
    md_integrity_register() and md_integrity_add_rdev() which are both
    personality-independent.

    md_integrity_register() is called from the ->run and ->hot_remove
    methods of all personalities that support data integrity. The
    function iterates over the component devices of the array and
    determines if all active devices are integrity capable and if their
    profiles match. If this is the case, the common profile is registered
    for the mddev via blk_integrity_register().

    The second new function, md_integrity_add_rdev() is called from the
    ->hot_add_disk methods, i.e. whenever a new device is being added
    to a raid array. If the new device does not support data integrity,
    or has a profile different from the one already registered, data
    integrity for the mddev is disabled.

    For raid0 and linear, only the call to md_integrity_register() from
    the ->run method is necessary.

    Signed-off-by: Andre Noll
    Signed-off-by: NeilBrown

    Andre Noll
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog:
    [WATCHDOG] Fix COH 901 327 watchdog enablement

    Linus Torvalds
     
  • * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
    eeepc-laptop: fix hot-unplug on resume
    ACPI: Ingore the memory block with zero block size in course of memory hotplug
    ACPI: Don't treat generic error as ACPI error code in acpi memory hotplug driver
    ACPI: bind workqueues to CPU 0 to avoid SMI corruption
    ACPI: root-only read protection on /sys/firmware/acpi/tables/*
    thinkpad-acpi: fix incorrect use of TPACPI_BRGHT_MODE_ECNVRAM
    thinkpad-acpi: restrict procfs count value to sane upper limit
    thinkpad-acpi: remove dock and bay subdrivers
    thinkpad-acpi: disable broken bay and dock subdrivers
    hp-wmi: check that an input device exists in resume handler
    Revert "ACPICA: Remove obsolete acpi_os_validate_address interface"

    Linus Torvalds
     
  • Clearly, I am a glutton for punishment. I'll see if I can see Alan's
    changes through to the end, otherwise I'll be fending off a lot of bug
    reports for usb-serial devices.

    Cc: Alan Cox
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Linus Torvalds

    Greg Kroah-Hartman
     
  • This function has traditionally used "insert_resource()", because before
    commit cebd78a8c5 ("Fix pci_claim_resource") it used to just insert the
    resource into whatever root resource tree that was indicated by
    "pcibios_select_root()".

    So there Matthew fixed it to actually look up the proper parent
    resource, which means that now it's actively wrong to then traverse the
    resource tree any more: we already know exactly where the new resource
    should go.

    And when we then did commit a76117dfd6 ("x86: Use pci_claim_resource"),
    which changed the x86 PCI code from the open-coded

    pr = pci_find_parent_resource(dev, r);
    if (!pr || request_resource(pr, r) < 0) {

    to using

    if (pci_claim_resource(dev, idx) < 0) {

    that "insert_resource()" now suddenly became a problem, and causes a
    regression covered by

    http://bugzilla.kernel.org/show_bug.cgi?id=13891

    which this fixes.

    Reported-and-tested-by: Rafael J. Wysocki
    Cc: Matthew Wilcox
    Cc: Andrew Patterson
    Cc: Linux PCI
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • Since the COH 901 327 found in U300 is clocked at 32 kHz we need
    to wait for the interrupt clearing flag to propagate through
    hardware in order not to accidentally fire off any interrupts
    when we enable them.

    Signed-off-by: Linus Walleij
    Signed-off-by: Wim Van Sebroeck

    Linus Walleij
     
  • Len Brown
     
  • Len Brown
     
  • OOPS on resume when the wireless adaptor is disabled during suspend was
    introduced by "eeepc-laptop: read rfkill soft-blocked state on resume".

    Unable to handle kernel NULL pointer dereference

    Process s2disk
    Tainted: G W
    IP: klist_put

    Call trace:
    ? klist_del
    ? device_del
    ? device_unregister
    ? pci_stop_dev
    ? pci_stop_bus
    ? pci_remove_device
    ? eeepc_rfkill_hotplug [eeepc_laptop]
    ? eeepc_hotk_resume [eeepc_laptop]
    ? acpi_device_resume
    ? device_resume
    ? hibernation_snapshot

    It appears the PCI device is removed twice. The eeepc_rfkill_hotplug()
    call from the resume handler is racing against the call from the ACPI
    notifier callback. The ACPI notification is triggered by the resume
    handler when it refreshes the value of CM_ASL_WLAN.

    The fix is to serialize hotplug calls using a workqueue.

    http://bugzilla.kernel.org/show_bug.cgi?id=13825

    Signed-off-by: Alan Jenkins
    Acked-by: Corentin Chary
    Signed-off-by: Len Brown

    Alan Jenkins
     
  • Len Brown
     
  • If the memory block size is zero, ignore it and don't do the memory hotplug
    flowchart. Otherwise it will complain the following warning message:
    >System RAM resource 0 - ffffffffffffffff cannot be added

    Signed-off-by: Zhao Yakui
    Signed-off-by: Len Brown

    Zhao Yakui
     
  • Don't treat the generic error as ACPI error code. Otherwise when the generic
    code is returned, it will complain the following warning messag:
    >ACPI Exception (acpi_memhotplug-0171): UNKNOWN_STATUS_CODE,
    Cannot get acpi bus device [20080609]
    >ACPI: Cannot find driver data
    > ACPI Error (utglobal-0127): Unknown exception code: 0xFFFFFFED [20080609]
    > Pid: 85, comm: kacpi_notify Not tainted 2.6.27.19-5-default #1
    Call Trace:
    [] show_trace_log_lvl+0x41/0x58
    [] dump_stack+0x69/0x6f
    .....

    At the same time when the generic error code is returned, the ACPI_EXCEPTION
    is replaced by the printk.

    Signed-off-by: Zhao Yakui
    Signed-off-by: Len Brown

    Zhao Yakui
     
  • Len Brown
     
  • On some machines, a software-initiated SMI causes corruption unless the
    SMI runs on CPU 0. An SMI can be initiated by any AML, but typically it's
    done in GPE-related methods that are run via workqueues, so we can avoid
    the known corruption cases by binding the workqueues to CPU 0.

    References:
    http://bugzilla.kernel.org/show_bug.cgi?id=13751
    https://bugs.launchpad.net/bugs/157171
    https://bugs.launchpad.net/bugs/157691

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Len Brown

    Bjorn Helgaas
     

02 Aug, 2009

10 commits

  • Len Brown
     
  • Len Brown
     
  • Len Brown
     
  • they were world readable.

    Signed-off-by: Len Brown

    Len Brown
     
  • HBRV-based default selection of backlight control strategy didn't work
    well, at least the X41 defines it but doesn't use it and I don't think
    it will stop there.

    Switch to a white/blacklist. All models that have HBRV defined have
    been included in the list, and initially all ATI GPUs will get
    ECNVRAM, and the Intel GPUs will get UCMS_STEP.

    Symptoms of incorrect backlight mode selection are:

    1. Non-working backlight control through sysfs;

    2. Backlight gets reset to the lowest level at every shutdown, reboot
    and when thinkpad-acpi gets unloaded;

    This fixes a regression in 2.6.30, bugzilla #13826

    Signed-off-by: Henrique de Moraes Holschuh
    Reported-by: Tobias Diedrich
    Cc: stable@kernel.org
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     
  • Signed-off-by: Michael Buesch
    Acked-by: Henrique de Moraes Holschuh
    Signed-off-by: Len Brown

    Michael Buesch
     
  • The standard ACPI dock driver can handle the hotplug bays and docks of
    the ThinkPads just fine (including batteries) as of 2.6.27, and the
    code in thinkpad-acpi for the dock and bay subdrivers is currently
    broken anyway...

    Userspace needs some love to support the two-stage ejection nicely,
    but it is simple enough to do through udev rules (you don't even need
    HAL) so this wouldn't justify fixing the dock and bay subdrivers,
    either.

    That leaves warm-swap bays (_EJ3) support for thinkpad-acpi, as well
    as support for the weird dock of the model 570, but since such support
    has never left the "experimental" stage, it is also not a strong
    enough reason to find a way to fix this code.

    Users of ThinkPads with warm-swap bays are urged to request that _EJ3
    support be added to the regular ACPI dock driver, if such feature is
    indeed useful for them.

    Signed-off-by: Henrique de Moraes Holschuh
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     
  • Currently, the ThinkPad-ACPI bay and dock drivers are completely
    broken, and cause a NULL pointer derreference in kernel mode (and,
    therefore, an OOPS) when they try to issue events (i.e. on dock,
    undock, bay ejection, etc).

    OTOH, the standard ACPI dock driver can handle the hotplug bays and
    docks of the ThinkPads just fine (including batteries) as of 2.6.27.
    In fact, it does a much better job of it than thinkpad-acpi ever did.

    It is just not worth the hassle to find a way to fix this crap without
    breaking the (deprecated) thinkpad-acpi dock/bay ABI. This is old,
    deprecated code that sees little testing or use.

    As a quick fix suitable for -stable backports, mark the thinkpad-acpi
    bay and dock subdrivers as BROKEN in Kconfig. The dead code will be
    removed by a later patch.

    This fixes bugzilla #13669, and should be applied to 2.6.27 and later.

    Signed-off-by: Henrique de Moraes Holschuh
    Reported-by: Joerg Platte
    Cc: stable@kernel.org
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     
  • The previous commit ("do_sigaltstack: avoid copying 'stack_t' as a
    structure to user space") fixed a real bug. This one just cleans up the
    copy from user space to that gcc can generate better code for it (and so
    that it looks the same as the later copy back to user space).

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • Ulrich Drepper correctly points out that there is generally padding in
    the structure on 64-bit hosts, and that copying the structure from
    kernel to user space can leak information from the kernel stack in those
    padding bytes.

    Avoid the whole issue by just copying the three members one by one
    instead, which also means that the function also can avoid the need for
    a stack frame. This also happens to match how we copy the new structure
    from user space, so it all even makes sense.

    [ The obvious solution of adding a memset() generates horrid code, gcc
    does really stupid things. ]

    Reported-by: Ulrich Drepper
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

01 Aug, 2009

6 commits


31 Jul, 2009

2 commits