Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Jun 24, 2008
  1. @gregkh


    gregkh authored
  2. @torvalds @gregkh

    Fix ZERO_PAGE breakage with vmware

    torvalds authored gregkh committed
    commit 672ca28 upstream
    Commit 89f5b7d ("Reinstate ZERO_PAGE
    optimization in 'get_user_pages()' and fix XIP") broke vmware, as
    reported by Jeff Chua:
      "This broke vmware 6.0.4.
       Jun 22 14:53:03.845: vmx| NOT_IMPLEMENTED
    and the reason seems to be that there's an old bug in how we handle do
    FOLL_ANON on VM_SHARED areas in get_user_pages(), but since it only
    triggered if the whole page table was missing, nobody had apparently hit
    it before.
    The recent changes to 'follow_page()' made the FOLL_ANON logic trigger
    not just for whole missing page tables, but for individual pages as
    well, and exposed this problem.
    This fixes it by making the test for when FOLL_ANON is used more
    careful, and also makes the code easier to read and understand by moving
    the logic to a separate inline function.
    Reported-and-tested-by: Jeff Chua <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  3. @gregkh

    hwmon: (adt7473) Initialize max_duty_at_overheat before use

    Jean Delvare authored gregkh committed
    commit ed4ec81 upstream
    data->max_duty_at_overheat is not updated in adt7473_update_device,
    so it might be used before it is initialized (if the user reads from
    sysfs file max_duty_at_crit before writing to it.)
    Signed-off-by: Jean Delvare <>
    Acked-by: Darrick J. Wong <>
    Signed-off-by: Mark M. Hoffman <>
    Signed-off-by: Greg Kroah-Hartman <>
  4. @gregkh

    hwmon: (lm85) Fix function RANGE_TO_REG()

    Jean Delvare authored gregkh committed
    Function RANGE_TO_REG() is broken. For a requested range of 2000 (2
    degrees C), it will return an index value of 15, i.e. 80.0 degrees C,
    instead of the expected index value of 0. All other values are handled
    properly, just 2000 isn't.
    The bug was introduced back in November 2004 by this patch:;a=commit;h=1c28d80f1992240373099d863e4996cdd5d646d0
    In Linus' kernel I decided to rewrite the whole function in a way
    which was more obviously correct. But for -stable let's just do the
    minimal fix.
    Signed-off-by: Jean Delvare <>
    Signed-off-by: Greg Kroah-Hartman <>
  5. @torvalds @gregkh

    watchdog: hpwdt: fix use of inline assembly

    torvalds authored gregkh committed
    commit 1f6ef23 upstream
    The inline assembly in drivers/watchdog/hpwdt.c was incredibly broken,
    and included all the function prologue and epilogue stuff, even though
    it was itself then inside a C function where the compiler would add its
    own prologue and epilogue on top of it all.
    This then just _happened_ to work if you had exactly the right compiler
    version and exactly the right compiler flags, so that gcc just happened
    to not create any prologue at all (the gcc-generated epilogue wouldn't
    matter, since it would never be reached).
    But the more proper way to fix it is to simply not do this.  Move the
    inline asm to the top level, with no surrounding function at all (the
    better alternative would be to remove the prologue and make it actually
    use proper description of the arguments to the inline asm, but that's a
    bigger change than the one I'm willing to make right now).
    Tested-by: S.Çağlar Onur <>
    Acked-by: Thomas Mingarelli <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  6. @jsgf @gregkh

    x86: set PAE PHYSICAL_MASK_SHIFT to 44 bits.

    jsgf authored gregkh committed
    commit ad524d4 upstream
    When a 64-bit x86 processor runs in 32-bit PAE mode, a pte can
    potentially have the same number of physical address bits as the
    64-bit host ("Enhanced Legacy PAE Paging").  This means, in theory,
    we could have up to 52 bits of physical address in a pte.
    The 32-bit kernel uses a 32-bit unsigned long to represent a pfn.
    This means that it can only represent physical addresses up to 32+12=44
    bits wide.  Rather than widening pfns everywhere, just set 2^44 as the
    Linux x86_32-PAE architectural limit for physical address size.
    This is a bugfix for two cases:
    1. running a 32-bit PAE kernel on a machine with
      more than 64GB RAM.
    2. running a 32-bit PAE Xen guest on a host machine with
      more than 64GB RAM
    In both cases, a pte could need to have more than 36 bits of physical,
    and masking it to 36-bits will cause fairly severe havoc.
    Signed-off-by: Jeremy Fitzhardinge <>
    Cc: Jan Beulich <>
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Greg Kroah-Hartman <>
  7. @gregkh

    x86: use BOOTMEM_EXCLUSIVE on 32-bit

    Bernhard Walle authored gregkh committed
    commit d3942cf upstream
    This patch uses the BOOTMEM_EXCLUSIVE for crashkernel reservation also for
    i386 and prints a error message on failure.
    The patch is still for 2.6.26 since it is only bug fixing. The unification
    of reserve_crashkernel() between i386 and x86_64 should be done for 2.6.27.
    Signed-off-by: Bernhard Walle <>
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Greg Kroah-Hartman <>
  8. @gregkh

    Add return value to reserve_bootmem_node()

    Bernhard Walle authored gregkh committed
    commit 71c2742 upstream
    This patch changes the function reserve_bootmem_node() from void to int,
    returning -ENOMEM if the allocation fails.
    This fixes a build problem on x86 with CONFIG_KEXEC=y and
    Signed-off-by: Bernhard Walle <>
    Reported-by: Adrian Bunk <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  9. @davem330 @gregkh

    sctp: Make sure N * sizeof(union sctp_addr) does not overflow.

    davem330 authored gregkh committed
    commit 735ce97 upstream
    As noticed by Gabriel Campana, the kmalloc() length arg
    passed in by sctp_getsockopt_local_addrs_old() can overflow
    if ->addr_num is large enough.
    Therefore, enforce an appropriate limit.
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
  10. @torvalds @gregkh

    Reinstate ZERO_PAGE optimization in 'get_user_pages()' and fix XIP

    torvalds authored gregkh committed
    commit 89f5b7d upstream
    KAMEZAWA Hiroyuki and Oleg Nesterov point out that since the commit
    557ed1f ("remove ZERO_PAGE") removed
    the ZERO_PAGE from the VM mappings, any users of get_user_pages() will
    generally now populate the VM with real empty pages needlessly.
    We used to get the ZERO_PAGE when we did the "handle_mm_fault()", but
    since fault handling no longer uses ZERO_PAGE for new anonymous pages,
    we now need to handle that special case in follow_page() instead.
    In particular, the removal of ZERO_PAGE effectively removed the core
    file writing optimization where we would skip writing pages that had not
    been populated at all, and increased memory pressure a lot by allocating
    all those useless newly zeroed pages.
    This reinstates the optimization by making the unmapped PTE case the
    same as for a non-existent page table, which already did this correctly.
    While at it, this also fixes the XIP case for follow_page(), where the
    caller could not differentiate between the case of a page that simply
    could not be used (because it had no "struct page" associated with it)
    and a page that just wasn't mapped.
    We do that by simply returning an error pointer for pages that could not
    be turned into a "struct page *".  The error is arbitrarily picked to be
    EFAULT, since that was what get_user_pages() already used for the
    equivalent IO-mapped page case.
    [ Also removed an impossible test for pte_offset_map_lock() failing:
      that's not how that function works ]
    Acked-by: Oleg Nesterov <>
    Acked-by: Nick Piggin <>
    Cc: KAMEZAWA Hiroyuki <>
    Cc: Hugh Dickins <>
    Cc: Andrew Morton <>
    Cc: Ingo Molnar <>
    Cc: Roland McGrath <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  11. @gregkh

    atl1: relax eeprom mac address error check

    Radu Cristescu authored gregkh committed
    upstream commit: 58c7821
    The atl1 driver tries to determine the MAC address thusly:
    	- If an EEPROM exists, read the MAC address from EEPROM and
    	  validate it.
    	- If an EEPROM doesn't exist, try to read a MAC address from
    	  SPI flash.
    	- If that fails, try to read a MAC address directly from the
    	  MAC Station Address register.
    	- If that fails, assign a random MAC address provided by the
    We now have a report of a system fitted with an EEPROM containing all
    zeros where we expect the MAC address to be, and we currently handle
    this as an error condition.  Turns out, on this system the BIOS writes
    a valid MAC address to the NIC's MAC Station Address register, but we
    never try to read it because we return an error when we find the all-
    zeros address in EEPROM.
    This patch relaxes the error check and continues looking for a MAC
    address even if it finds an illegal one in EEPROM.
    [ backport to]
    Signed-off-by: Radu Cristescu <>
    Signed-off-by: Jay Cliburn <>
    Signed-off-by: Jeff Garzik <>
    Signed-off-by: Greg Kroah-Hartman <>
Commits on Jun 22, 2008
  1. @gregkh


    gregkh authored
  2. @gregkh

    x86: disable mwait for AMD family 10H/11H CPUs

    Thomas Gleixner authored gregkh committed
    back-ported from upstream commit e9623b3 by Vegard Nossum
    The previous revert of 0c07ee3 left
    out the mwait disable condition for AMD family 10H/11H CPUs.
    Andreas Herrman said:
    It depends on the CPU. For AMD CPUs that support MWAIT this is wrong.
    Family 0x10 and 0x11 CPUs will enter C1 on HLT. Powersavings then
    depend on a clock divisor and current Pstate of the core.
    If all cores of a processor are in halt state (C1) the processor can
    enter the C1E (C1 enhanced) state. If mwait is used this will never
    Thus HLT saves more power than MWAIT here.
    It might be best to switch off the mwait flag for these AMD CPU
    families like it was introduced with commit
    f039b75 (x86: Don't use MWAIT on AMD
    Family 10)
    Re-add the AMD families 10H/11H check and disable the mwait usage for
    Signed-off-by: Thomas Gleixner <>
    Signed-off-by: Vegard Nossum <>
    Cc: Ingo Molnar <>
    Signed-off-by: Greg Kroah-Hartman <>
  3. @gregkh

    x86: remove mwait capability C-state check

    Ingo Molnar authored gregkh committed
    back-ported from upstream commit a738d89 by Vegard Nossum
    Vegard Nossum reports:
    | powertop shows between 200-400 wakeups/second with the description
    | "<kernel IPI>: Rescheduling interrupts" when all processors have load (e.g.
    | I need to run two busy-loops on my 2-CPU system for this to show up).
    | The bisect resulted in this commit:
    | commit 0c07ee3
    | Date:   Wed Jan 30 13:33:16 2008 +0100
    |     x86: use the correct cpuid method to detect MWAIT support for C states
    remove the functional effects of this patch and make mwait unconditional.
    A future patch will turn off mwait on specific CPUs where that causes
    power to be wasted.
    Bisected-by: Vegard Nossum <>
    Tested-by: Vegard Nossum <>
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Vegard Nossum <>
    Signed-off-by: Greg Kroah-Hartman <>
  4. @kaber @gregkh

    nf_conntrack_h323: fix memory leak in module initialization error path

    kaber authored gregkh committed
    netfilter: nf_conntrack_h323: fix memory leak in module initialization error path
    Upstream commit 8a54886
    Properly free h323_buffer when helper registration fails.
    Signed-off-by: Patrick McHardy <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
  5. @kaber @gregkh

    nf_conntrack_h323: fix module unload crash

    kaber authored gregkh committed
    netfilter: nf_conntrack_h323: fix module unload crash
    Upstream commit a56b8f8
    The H.245 helper is not registered/unregistered, but assigned to
    connections manually from the Q.931 helper. This means on unload
    existing expectations and connections using the helper are not
    cleaned up, leading to the following oops on module unload:
    CPU 0 Unable to handle kernel paging request at virtual address c00a6828, epc == 802224dc, ra == 801d4e7c
    Cpu 0
    $ 0   : 00000000 00000000 00000004 c00a67f0
    $ 4   : 802a5ad0 81657e00 00000000 00000000
    $ 8   : 00000008 801461c8 00000000 80570050
    $12   : 819b0280 819b04b0 00000006 00000000
    $16   : 802a5a60 80000000 80b46000 80321010
    $20   : 00000000 00000004 802a5ad0 00000001
    $24   : 00000000 802257a8
    $28   : 802a4000 802a59e8 00000004 801d4e7c
    Hi    : 0000000b
    Lo    : 00506320
    epc   : 802224dc ip_conntrack_help+0x38/0x74     Tainted: P
    ra    : 801d4e7c nf_iterate+0xbc/0x130
    Status: 1000f403    KERNEL EXL IE
    Cause : 00800008
    BadVA : c00a6828
    PrId  : 00019374
    Modules linked in: ip_nat_pptp ip_conntrack_pptp ath_pktlog wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_xauth ath_pci ath_dev ath_dfs ath_rate_atheros wlan ath_hal ip_nat_tftp ip_conntrack_tftp ip_nat_ftp ip_conntrack_ftp pppoe ppp_async ppp_deflate ppp_mppe pppox ppp_generic slhc
    Process swapper (pid: 0, threadinfo=802a4000, task=802a6000)
    Stack : 801e7d98 00000004 802a5a60 80000000 801d4e7c 801d4e7c 802a5ad0 00000004
            00000000 00000000 801e7d98 00000000 00000004 802a5ad0 00000000 00000010
            801e7d98 80b46000 802a5a60 80320000 80000000 801d4f8c 802a5b00 00000002
            80063834 00000000 80b46000 802a5a60 801e7d98 80000000 802ba854 00000000
            81a02180 80b7e260 81a021b0 819b0000 819b0000 80570056 00000000 00000001
    Call Trace:
     [<801e7d98>] ip_finish_output+0x0/0x23c
     [<801d4e7c>] nf_iterate+0xbc/0x130
     [<801d4e7c>] nf_iterate+0xbc/0x130
     [<801e7d98>] ip_finish_output+0x0/0x23c
     [<801e7d98>] ip_finish_output+0x0/0x23c
     [<801d4f8c>] nf_hook_slow+0x9c/0x1a4
    One way to fix this would be to split helper cleanup from the unregistration
    function and invoke it for the H.245 helper, but since ctnetlink needs to be
    able to find the helper for synchonization purposes, a better fix is to
    register it normally and make sure its not assigned to connections during
    helper lookup. The missing l3num initialization is enough for this, this
    patch changes it to use AF_UNSPEC to make it more explicit though.
    Reported-by: liannan <>
    Signed-off-by: Patrick McHardy <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
  6. @kaber @gregkh

    nf_conntrack: fix ctnetlink related crash in nf_nat_setup_info()

    kaber authored gregkh committed
    netfilter: nf_conntrack: fix ctnetlink related crash in nf_nat_setup_info()
    Upstream commit ceeff75
    When creation of a new conntrack entry in ctnetlink fails after having
    set up the NAT mappings, the conntrack has an extension area allocated
    that is not getting properly destroyed when freeing the conntrack again.
    This means the NAT extension is still in the bysource hash, causing a
    crash when walking over the hash chain the next time:
    BUG: unable to handle kernel paging request at 00120fbd
    IP: [<c03d394b>] nf_nat_setup_info+0x221/0x58a
    *pde = 00000000
    Oops: 0000 [#1] PREEMPT SMP
    Pid: 2795, comm: conntrackd Not tainted (2.6.26-rc5 #1)
    EIP: 0060:[<c03d394b>] EFLAGS: 00010206 CPU: 1
    EIP is at nf_nat_setup_info+0x221/0x58a
    EAX: 00120fbd EBX: 00120fbd ECX: 00000001 EDX: 00000000
    ESI: 0000019e EDI: e853bbb4 EBP: e853bbc8 ESP: e853bb78
     DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
    Process conntrackd (pid: 2795, ti=e853a000 task=f7de10f0 task.ti=e853a000)
    Stack: 00000000 e853bc2c e85672ec 00000008 c0561084 63c1db4a 00000000 00000000
           00000000 0002e109 61d2b1c3 00000000 00000000 00000000 01114e22 61d2b1c3
           00000000 00000000 f7444674 e853bc04 00000008 c038e728 0000000a f7444674
    Call Trace:
     [<c038e728>] nla_parse+0x5c/0xb0
     [<c0397c1b>] ctnetlink_change_status+0x190/0x1c6
     [<c0397eec>] ctnetlink_new_conntrack+0x189/0x61f
     [<c0119aee>] update_curr+0x3d/0x52
     [<c03902d1>] nfnetlink_rcv_msg+0xc1/0xd8
     [<c0390228>] nfnetlink_rcv_msg+0x18/0xd8
     [<c0390210>] nfnetlink_rcv_msg+0x0/0xd8
     [<c038d2ce>] netlink_rcv_skb+0x2d/0x71
     [<c0390205>] nfnetlink_rcv+0x19/0x24
     [<c038d0f5>] netlink_unicast+0x1b3/0x216
    Move invocation of the extension destructors to nf_conntrack_free()
    to fix this problem.
    Reported-and-Tested-by: Krzysztof Piotr Oledzki <>
    Signed-off-by: Patrick McHardy <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
  7. @gregkh

    SCSI: sr: fix corrupt CD data after media change and delay

    James Bottomley authored gregkh committed
    commit: d1daeab upstream
    Reported-by: Geert Uytterhoeven <>
    If you delay 30s or more before mounting a CD after inserting it then
    the kernel has the wrong value for the CD size.
    The problem is in sr_test_unit_ready(): the function eats unit
    attentions without adjusting the sdev->changed status.  This means
    that when the CD signals changed media via unit attention, we can
    ignore it.  Fix by making sr_test_unit_ready() adjust the changed
    Reported-by: Geert Uytterhoeven <>
    Tested-by: Geert Uytterhoeven <>
    Signed-off-by: James Bottomley <>
    Signed-off-by: Greg Kroah-Hartman <>
  8. @acpibob @gregkh

    ACPICA: Ignore ACPI table signature for Load() operator

    acpibob authored gregkh committed
    upstream bc45b1d
    Without this patch booting with acpi_osi="!Windows 2006" is required
    for several machines to function properly with cpufreq
    due to failure to load a Vista specific table with a bad signature.
    Only "SSDT" is acceptable to the ACPI spec, but tables are
    seen with OEMx and null sigs. Therefore, signature validation
    is worthless.  Apparently MS ACPI accepts such signatures, ACPICA
    must be compatible.
    Signed-off-by: Bob Moore <>
    Signed-off-by: Lin Ming <>
    Signed-off-by: Len Brown <>
    Signed-off-by: Greg Kroah-Hartman <>
  9. @mikechristie @gregkh

    scsi_host regression: fix scsi host leak

    mikechristie authored gregkh committed
    The patch is upstream as commit 3ed7897
    A different backport is necessary because of the class_device to device
    conversion post 2.6.25.
    commit 9c77010
    Author: Dave Young <>
    Date:   Tue Jan 22 14:01:34 2008 +0800
        scsi: use class iteration api
    Isn't a correct replacement for the original hand rolled host
    lookup. The problem is that class_find_child would get a reference to
    the host's class device which is never released.  Since the host class
    device holds a reference to the host gendev, the host can never be
    In 2.6.25 we started using class_find_device, and this function also
    gets a reference to the device, so we end up with an extra ref
    and the host will not get released.
    This patch adds a class_put_device to balance the class_find_device()
    get. I kept the scsi_host_get in scsi_host_lookup, because the target
    layer is using scsi_host_lookup and it looks like it needs the SHOST_DEL
    Signed-off-by: Mike Christie <>
    Signed-off-by: James Bottomley <>
    Signed-off-by: Greg Kroah-Hartman <>
  10. @gregkh

    b43: Fix possible NULL pointer dereference in DMA code

    Michael Buesch authored gregkh committed
    a cut-down version of commit 028118a upstream
    This fixes a possible NULL pointer dereference in an error path of the
    DMA allocation error checking code. In case the DMA allocation address is invalid,
    the dev pointer is dereferenced for unmapping of the buffer.
    Reported-by: Miles Lane <>
    Signed-off-by: Michael Buesch <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
  11. @gregkh

    b43: Fix noise calculation WARN_ON

    Michael Buesch authored gregkh committed
    commit 98a3b2f upstream.
    This removes a WARN_ON that is responsible for the following koops:
    The comment in the patch describes why it's safe to simply remove
    the check.
    Signed-off-by: Michael Buesch <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
  12. @markmc @gregkh

    virtio_net: Fix skb->csum_start computation

    markmc authored gregkh committed
    commit 23cde76 upstream.
    hdr->csum_start is the offset from the start of the ethernet
    header to the transport layer checksum field. skb->csum_start
    is the offset from skb->head.
    skb_partial_csum_set() assumes that skb->data points to the
    ethernet header - i.e. it computes skb->csum_start by adding
    the headroom to hdr->csum_start.
    Since eth_type_trans() skb_pull()s the ethernet header,
    skb_partial_csum_set() should be called before
    (Without this patch, GSO packets from a guest to the world outside the
    host are corrupted).
    Signed-off-by: Mark McLoughlin <>
    Acked-by: Herbert Xu <>
    Signed-off-by: Rusty Russell <>
    Signed-off-by: Greg Kroah-Hartman <>
  13. @bzolnier @gregkh

    opti621: remove DMA support

    bzolnier authored gregkh committed
    commit f361037 upstream
    These controllers don't support DMA.
    Based on a bugreport from Juergen Kosel & inspired by pata_opti.c code.
    Tested-by: Juergen Kosel <>
    Acked-by: Sergei Shtylyov <>
    Signed-off-by: Bartlomiej Zolnierkiewicz <>
    Signed-off-by: Greg Kroah-Hartman <>
  14. @bzolnier @gregkh

    opti621: disable read prefetch

    bzolnier authored gregkh committed
    commit 62128b2 upstream
    This fixes 2.6.25 regression ( bugzilla bug #10723) caused by:
    commit 912fb29
    Author: Bartlomiej Zolnierkiewicz <>
    Date:   Fri Oct 19 00:30:11 2007 +0200
        opti621: always tune PIO
    Based on a bugreport from Juergen Kosel & inspired by pata_opti.c code.
    Bisected-by: Juergen Kosel <>
    Tested-by: Juergen Kosel <>
    Signed-off-by: Bartlomiej Zolnierkiewicz <>
    Signed-off-by: Greg Kroah-Hartman <>
  15. @Alan-Cox @gregkh

    Fix tty speed handling on 8250

    Alan-Cox authored gregkh committed
    commit e991a2b upstream.
    We try and write the correct speed back but the serial midlayer already
    mangles the speed on us and that means if we request B0 we report back B9600
    when we should not.  For now we'll hack around this in the drivers and serial
    code, pending a better long term solution.
    Signed-off-by: Alan Cox <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  16. @torvalds @gregkh

    x86-64: Fix "bytes left to copy" return value for copy_from_user()

    torvalds authored gregkh committed
    commit 42a886a upstream
    Most users by far do not care about the exact return value (they only
    really care about whether the copy succeeded in its entirety or not),
    but a few special core routines actually care deeply about exactly how
    many bytes were copied from user space.
    And the unrolled versions of the x86-64 user copy routines would
    sometimes report that it had copied more bytes than it actually had.
    Very few uses actually have partial copies to begin with, but to make
    this bug even harder to trigger, most x86 CPU's use the "rep string"
    instructions for normal user copies, and that version didn't have this
    To make it even harder to hit, the one user of this that really cared
    about the return value (and used the uncached version of the copy that
    doesn't use the "rep string" instructions) was the generic write
    routine, which pre-populated its source, once more hiding the problem by
    avoiding the exception case that triggers the bug.
    In other words, very special thanks to Bron Gondwana who not only
    triggered this, but created a test-program to show it, and bisected the
    behavior down to commit 0829142 ("mm:
    fix pagecache write deadlocks") which changed the access pattern just
    enough that you can now trigger it with 'writev()' with multiple
    That commit itself was not the cause of the bug, it just allowed all the
    stars to align just right that you could trigger the problem.
    [ Side note: this is just the minimal fix to make the copy routines
      (with __copy_from_user_inatomic_nocache as the particular version that
      was involved in showing this) have the right return values.
      We really should improve on the exceptional case further - to make the
      copy do a byte-accurate copy up to the exact page limit that causes it
      to fail.  As it is, the callers have to do extra work to handle the
      limit case gracefully. ]
    Reported-by: Bron Gondwana <>
    Cc: Nick Piggin <>
    Cc: Andrew Morton <>
    Cc: Andi Kleen <>
    Cc: Al Viro <>
    Acked-by: Ingo Molnar <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
Commits on Jun 16, 2008
  1. @gregkh


    gregkh authored
  2. @dcbw @gregkh

    mac80211: send association event on IBSS create

    dcbw authored gregkh committed
    patch 507b06d upstream
    Otherwise userspace has no idea the IBSS creation succeeded.
    Signed-off-by: Dan Williams <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
  3. @gregkh

    x86: fix recursive dependencies

    Roman Zippel authored gregkh committed
    commit 823c248 in mainline
    The proper dependency check uncovered a few dependency problems,
    the subarchitecture used a mixture of selects and depends on SMP
    and PCI dependency was messed up.
    Signed-off-by: Roman Zippel <>
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Ravikiran Thirumalai <>
  4. @fenrus75 @gregkh

    bttv: Fix a deadlock in the bttv driver

    fenrus75 authored gregkh committed
    commit 81b2dbc in mainline.
    vidiocgmbuf() does this:
            retval = videobuf_mmap_setup(&fh->cap, gbuffers, gbufsize,
    and videobuf_mmap_setup() then just does
            ret = __videobuf_mmap_setup(q, bcount, bsize, memory);
    which is an obvious double-take deadlock.
    This patch fixes this by having vidiocgmbuf() just call the
    __videobuf_mmap_setup function instead.
    Acked-by: Mauro Carvalho Chehab <>
    Reported-by: Koos Vriezen <>
    Signed-off-by: Arjan van de Ven <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  5. @gregkh

    Kconfig: introduce ARCH_DEFCONFIG to DEFCONFIG_LIST

    Sam Ravnborg authored gregkh committed
    commit 7353190 in mainline.
    init/Kconfig contains a list of configs that are searched
    for if 'make *config' are used with no .config present.
    Extend this list to look at the config identified by
    With this change we now try the defconfig targets last.
    This fixes a regression reported
    by: Linus Torvalds <>
    Signed-off-by: Sam Ravnborg <>
    Cc: Linus Torvalds <>
    Cc: Thomas Gleixner <>
    Cc: Ingo Molnar <>
    Cc: "H. Peter Anvin" <>
    Signed-off-by: Greg Kroah-Hartman <>
  6. @fenrus75 @gregkh

    serial: fix enable_irq_wake/disable_irq_wake imbalance in serial_core.c

    fenrus75 authored gregkh committed
    commit 03a74dc in mainline.
    enable_irq_wake() and disable_irq_wake() need to be balanced.  However,
    serial_core.c calls these for different conditions during the suspend and
    resume functions...
    This is causing a regular WARN_ON() as found at
    This patch makes the conditions for triggering the _wake enable/disable
    sequence identical.
    Signed-off-by: Arjan van de Ven <>
    Cc: Alan Cox <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  7. @chriswright @gregkh

    CPUFREQ: Fix format string bug.

    chriswright authored gregkh committed
    commit 326f6a5 upstream
    Format string bug.  Not exploitable, as this is only writable by root,
    but worth fixing all the same.
    From: Chris Wright <>
    Spotted-by: Ilja van Sprundel <>
    Signed-off-by: Dave Jones <>
    Signed-off-by: Greg Kroah-Hartman <>
  8. @mslusarz @gregkh

    cifs: fix oops on mount when CONFIG_CIFS_DFS_UPCALL is enabled

    mslusarz authored gregkh committed
    simple "mount -t cifs //xxx /mnt" oopsed on strlen of options \
    Signed-off-by: Marcin Slusarz <>
    Acked-by: Jeff Layton <>
    Signed-off-by: Steve French <>
    Signed-off-by: Greg Kroah-Hartman <>
Something went wrong with that request. Please try again.