Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Sep 25, 2007
  1. @gregkh

    Linux 2.6.22.8

    gregkh authored
  2. @tiwai @gregkh

    Convert snd-page-alloc proc file to use seq_file (CVE-2007-4571)

    tiwai authored gregkh committed
    changeset ccec6e2 in mainline.
    
    Use seq_file for the proc file read/write of snd-page-alloc module.
    This automatically fixes bugs in the old proc code.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commits on Sep 21, 2007
  1. @chriswright

    Linux 2.6.22.7

    chriswright authored
  2. @chriswright

    [PATCH] x86_64: Zero extend all registers after ptrace in 32bit entry…

    Andi Kleen authored chriswright committed
    … path.
    
    Strictly it's only needed for eax.
    
    It actually does a little more than strictly needed -- the other registers
    are already zero extended.
    
    Also remove the now unnecessary and non functional compat task check
    in ptrace.
    
    This is CVE-2007-4573
    
    Found by Wojciech Purczynski
    
    Signed-off-by: Andi Kleen <ak@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Commits on Aug 31, 2007
  1. @gregkh

    Linux 2.6.22.6

    gregkh authored
  2. @kaysievers @gregkh

    usb: add PRODUCT, TYPE to usb-interface events

    kaysievers authored gregkh committed
    This fixes a regression for userspace programs that were relying on these events.
    
    
    Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
    Cc: Andreas Jellinghaus <aj@ciphirelabs.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @gregkh

    USB: fix DoS in pwc USB video driver

    Oliver Neukum authored gregkh committed
    the pwc driver has a disconnect method that waits for user space to
    close the device. This opens up an opportunity for a DoS attack,
    blocking the USB subsystem and making khubd's task busy wait in
    kernel space. This patch shifts freeing resources to close if an opened
    device is disconnected.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @gregkh

    USB: allow retry on descriptor fetch errors

    Alan Stern authored gregkh committed
    This patch (as964) was suggested by Steffen Koepf.  It makes
    usb_get_descriptor() retry on all errors other than ETIMEDOUT, instead
    of only on EPIPE.  This helps with some devices.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @htejun @gregkh

    PCI: disable MSI on RX790

    htejun authored gregkh committed
    RX790 can't do MSI like its predecessors.  Disable MSI on RX790.
    
    Signed-off-by: Tejun Heo <htejun@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @htejun @gregkh

    PCI: disable MSI on RD580

    htejun authored gregkh committed
    RD580 can't do MSI like its predecessors.  Disable MSI on RD580.
    
    Signed-off-by: Tejun Heo <teheo@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @htejun @gregkh

    PCI: disable MSI on RS690

    htejun authored gregkh committed
    RS690 can't do MSI like its predecessors.  Disable MSI on RS690.
    
    Signed-off-by: Tejun Heo <htejun@gmail.com>
    Cc: Henry Su <henry.su@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @gregkh

    PCI: lets kill the 'PCI hidden behind bridge' message

    Bernhard Kaindl authored gregkh committed
    Adrian Bunk wrote:
    > Alois Nešpor wrote
    >> PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0b) (try 'pci=assign-busses')
    >> Please report the result to linux-kernel to fix this permanently"
    >>
    >> dmesg:
    >> "Yenta: Raising subordinate bus# of parent bus (#0a) from #0b to #0e"
    >> without pci=assign-busses and nothing with pci=assign-busses.
    >
    > Bernhard?
    
    Ok, lets kill the message. As Alois Nešpor also saw, that's fixed up by Yenta,
    so PCI does not have to warn about it. PCI could still warn about it if
    is_cardbus is 0 in that instance of pci_scan_bridge(), but so far I have
    not seen a report where this would have been the case so I think we can
    spare the kernel of that check (removes ~300 lines of asm) unless debugging
    is done.
    
    History: The whole check was added in the days before we had the fixup
    for this in Yenta and pci=assign-busses was the only way to get CardBus
    cards detected on many (not all) of the machines which give this warning.
    
    In theory, there could be cases when this warning would be triggered and
    it's not cardbus, then the warning should still apply, but I think this
    should only be the case when working on a completely broken PCI setup,
    but one may have already enabled the debug code in drivers/pci and the
    patched check would then trigger.
    
    I do not sign this off yet because it's completely untested so far, but
    everyone is free to test it (with the #ifdef DEBUG replaced by #if 1 and
    pr_debug( changed to printk(.
    
    We may also dump the whole check (remove everything within the #ifdef from
    the source) if that's perferred.
    
    On Alois Nešpor's machine this would then (only when debugging) this message:
    
    "PCI: Bus #0b (-#0e) is partially hidden behind transparent bridge #0a (-#0b)"
    
    "partially" should be in the message on his machine because #0b of #0b-#0e
    is reachable behind #0a-#0b, but not #0c-#0e.
    
    But that differentiation is now moot anyway because the fixup in Yenta takes
    care of it as far as I could see so far, which means that unless somebody
    is debugging a totally broken PCI setup, this message is not needed anymore,
    not even for debugging PCI.
    
    
    Ok, here the patch with the following changes:
    
    * Refined to say that the bus is only partially hidden when the parent
      bus numbers are not totally way off (outside of) the child bus range
    * remove the reference to pci=assign-busses and the plea to report it
    
    We could add a pure source code-only comment to keep a reference to
    pci=assign-busses the in case when this is triggered by someone who
    is debugging the cause of this message and looking the way to solve it.
    
    From: Bernhard Kaindl <bk@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @digitalentity @gregkh

    PPP: Fix PPP buffer sizing.

    digitalentity authored gregkh committed
    This patch addresses the issue with "osize too small" errors in mppe
    encryption.  The patch fixes the issue with wrong output buffer size
    being passed to ppp decompression routine.
    
    --------------------
    As pointed out by Suresh Mahalingam, the issue addressed by
    ppp-fix-osize-too-small-errors-when-decoding patch is not fully resolved yet.
    The size of allocated output buffer is correct, however it size passed to
    ppp->rcomp->decompress in ppp_generic.c if wrong. The patch fixes that.
    --------------------
    
    Signed-off-by: Konstantin Sharlaimov <konstantin.sharlaimov@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @gregkh

    TCP: Fix TCP handling of SACK in bidirectional flows.

    Ilpo Järvinen authored gregkh committed
    It's possible that new SACK blocks that should trigger new LOST
    markings arrive with new data (which previously made is_dupack
    false). In addition, I think this fixes a case where we get
    a cumulative ACK with enough SACK blocks to trigger the fast
    recovery (is_dupack would be false there too).
    
    I'm not completely pleased with this solution because readability
    of the code is somewhat questionable as 'is_dupack' in SACK case
    is no longer about dupacks only but would mean something like
    'lost_marker_work_todo' too... But because of Eifel stuff done
    in CA_Recovery, the FLAG_DATA_SACKED check cannot be placed to
    the if statement which seems attractive solution. Nevertheless,
    I didn't like adding another variable just for that either... :-)
    
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @gregkh

    TCP: Fix TCP rate-halving on bidirectional flows.

    Ilpo Järvinen authored gregkh committed
    Actually, the ratehalving seems to work too well, as cwnd is
    reduced on every second ACK even though the packets in flight
    remains unchanged. Recoveries in a bidirectional flows suffer
    quite badly because of this, both NewReno and SACK are affected.
    
    After this patch, rate halving is performed for ACK only if
    packets in flight was supposedly changed too.
    
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @davem330 @gregkh

    TCP: Do not autobind ports for TCP sockets

    davem330 authored gregkh committed
    [TCP]: Invoke tcp_sendmsg() directly, do not use inet_sendmsg().
    
    As discovered by Evegniy Polyakov, if we try to sendmsg after
    a connection reset, we can do incredibly stupid things.
    
    The core issue is that inet_sendmsg() tries to autobind the
    socket, but we should never do that for TCP.  Instead we should
    just go straight into TCP's sendmsg() code which will do all
    of the necessary state and pending socket error checks.
    
    TCP's sendpage already directly vectors to tcp_sendpage(), so this
    merely brings sendmsg() in line with that.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @davem330 @gregkh

    SPARC64: Fix sparc64 PCI config accesses on sun4u

    davem330 authored gregkh committed
    [SPARC64]: Fix sun4u PCI config space accesses on sun4u.
    
    Don't provide fake PCI config space for sun4u.
    
    Also, put back the funny host controller space handling that
    at least Sabre needs.  You have to read PCI host controller
    registers at their nature size otherwise you get zeros instead
    of correct values.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @davem330 @gregkh

    SPARC64: Fix sparc64 task stack traces.

    davem330 authored gregkh committed
    It didn't handle that case at all, and now dump_stack()
    can be implemented directly as show_stack(current, NULL)
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @herbertx @gregkh

    NET: Fix missing rcu unlock in __sock_create()

    herbertx authored gregkh committed
    [NET]: Fix unbalanced rcu_read_unlock in __sock_create
    
    The recent RCU work created an unbalanced rcu_read_unlock
    in __sock_create.  This patch fixes that.  Reported by
    oleg 123.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @herbertx @gregkh

    SNAP: Fix SNAP protocol header accesses.

    herbertx authored gregkh committed
    The snap_rcv code reads 5 bytes so we should make sure that
    we have 5 bytes in the head before proceeding.
    
    Based on diagnosis and fix by Evgeniy Polyakov, reported by
    Alan J. Wylie.
    
    Patch also kills the skb->sk assignment before kfree_skb
    since it's redundant.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @gregkh

    Netfilter: Missing Kbuild entry for netfilter

    Chuck Ebbert authored gregkh committed
    Author: Chuck Ebbert <cebbert@redhat.com>
    
    Add xt_statistic.h to the list of headers to install.
    
    Apparently needed to build newer versions of iptables.
    
    Signed-off-by: Chuck Ebbert <cebbert@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @davem330 @gregkh

    Fix soft-fp underflow handling.

    davem330 authored gregkh committed
    The underflow exception cases were wrong.
    
    This is one weird area of ieee1754 handling in that the underflow
    behavior changes based upon whether underflow is enabled in the trap
    enable mask of the FPU control register.  As a specific case the Sparc
    V9 manual gives us the following description:
    
    --------------------
    If UFM = 0:     Underflow occurs if a nonzero result is tiny and a
                    loss of accuracy occurs.  Tininess may be detected
                    before or after rounding.  Loss of accuracy may be
                    either a denormalization loss or an inexact result.
    
    If UFM = 1:     Underflow occurs if a nonzero result is tiny.
                    Tininess may be detected before or after rounding.
    --------------------
    
    What this amounts to in the packing case is if we go subnormal,
    we set underflow if any of the following are true:
    
    1) rounding sets inexact
    2) we ended up rounding back up to normal (this is the case where
       we set the exponent to 1 and set the fraction to zero), this
       should set inexact too
    3) underflow is set in FPU control register trap-enable mask
    
    The initially discovered example was "DBL_MIN / 16.0" which
    incorrectly generated an underflow.  It should not, unless underflow
    is set in the trap-enable mask of the FPU csr.
    
    Another example, "0x0.0000000000001p-1022 / 16.0", should signal both
    inexact and underflow.  The cpu implementations and ieee1754
    literature is very clear about this.  This is case #2 above.
    
    However, if underflow is set in the trap enable mask, only underflow
    should be set and reported as a trap.  That is handled properly by the
    prioritization logic in
    
    arch/sparc{,64}/math-emu/math.c:record_exception().
    
    Based upon a report and test case from Jakub Jelinek.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @gregkh

    IPv6: Invalid semicolon after if statement

    Ilpo Jarvinen authored gregkh committed
    Author: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    
    A similar fix to netfilter from Eric Dumazet inspired me to
    look around a bit by using some grep/sed stuff as looking for
    this kind of bugs seemed easy to automate. This is one of them
    I found where it looks like this semicolon is not valid.
    
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. @gregkh

    IPV6: Fix kernel panic while send SCTP data with IP fragments

    Wei Yongjun authored gregkh committed
    If ICMP6 message with "Packet Too Big" is received after send SCTP DATA,
    kernel panic will occur when SCTP DATA is send again.
    
    This is because of a bad dest address when call to skb_copy_bits().
    
    The messages sequence is like this:
    
    Endpoint A                             Endpoint B
                                   <-------  SCTP DATA (size=1432)
    ICMP6 message ------->
    (Packet Too Big pmtu=1280)
                                   <-------  Resend SCTP DATA (size=1432)
    ------------kernel panic---------------
    
     printing eip:
    c05be62a
    *pde = 00000000
    Oops: 0002 [#1]
    SMP
    Modules linked in: scomm l2cap bluetooth ipv6 dm_mirror dm_mod video output sbs battery lp floppy sg i2c_piix4 i2c_core pcnet32 mii button ac parport_pc parport ide_cd cdrom serio_raw mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
    CPU:    0
    EIP:    0060:[<c05be62a>]    Not tainted VLI
    EFLAGS: 00010282   (2.6.23-rc2 #1)
    EIP is at skb_copy_bits+0x4f/0x1ef
    eax: 000004d0   ebx: ce12a980   ecx: 00000134   edx: cfd5a880
    esi: c8246858   edi: 00000000   ebp: c0759b14   esp: c0759adc
    ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
    Process swapper (pid: 0, ti=c0759000 task=c06d0340 task.ti=c0713000)
    Stack: c0759b88 c0405867 ce12a980 c8bff838 c789c084 00000000 00000028 cfd5a880
           d09f1890 000005dc 0000007b ce12a980 cfd5a880 c8bff838 c0759b88 d09bc521
           000004d0 fffff96c 00000200 00000100 c0759b50 cfd5a880 00000246 c0759bd4
    Call Trace:
     [<c0405e1d>] show_trace_log_lvl+0x1a/0x2f
     [<c0405ecd>] show_stack_log_lvl+0x9b/0xa3
     [<c040608d>] show_registers+0x1b8/0x289
     [<c0406271>] die+0x113/0x246
     [<c0625dbc>] do_page_fault+0x4ad/0x57e
     [<c0624642>] error_code+0x72/0x78
     [<d09bc521>] ip6_output+0x8e5/0xab2 [ipv6]
     [<d09bcec1>] ip6_xmit+0x2ea/0x3a3 [ipv6]
     [<d0a3f2ca>] sctp_v6_xmit+0x248/0x253 [sctp]
     [<d0a3c934>] sctp_packet_transmit+0x53f/0x5ae [sctp]
     [<d0a34bf8>] sctp_outq_flush+0x555/0x587 [sctp]
     [<d0a34d3c>] sctp_retransmit+0xf8/0x10f [sctp]
     [<d0a3d183>] sctp_icmp_frag_needed+0x57/0x5b [sctp]
     [<d0a3ece2>] sctp_v6_err+0xcd/0x148 [sctp]
     [<d09cf1ce>] icmpv6_notify+0xe6/0x167 [ipv6]
     [<d09d009a>] icmpv6_rcv+0x7d7/0x849 [ipv6]
     [<d09be240>] ip6_input+0x1dc/0x310 [ipv6]
     [<d09be965>] ipv6_rcv+0x294/0x2df [ipv6]
     [<c05c3789>] netif_receive_skb+0x2d2/0x335
     [<c05c5733>] process_backlog+0x7f/0xd0
     [<c05c58f6>] net_rx_action+0x96/0x17e
     [<c042e722>] __do_softirq+0x64/0xcd
     [<c0406f37>] do_softirq+0x5c/0xac
     =======================
    Code: 00 00 29 ca 89 d0 2b 45 e0 89 55 ec 85 c0 7e 35 39 45 08 8b 55 e4 0f 4e 45 08 8b 75 e0 8b 7d dc 89 c1 c1 e9 02 03 b2 a0 00 00 00 <f3> a5 89 c1 83 e1 03 74 02 f3 a4 29 45 08 0f 84 7b 01 00 00 01
    EIP: [<c05be62a>] skb_copy_bits+0x4f/0x1ef SS:ESP 0068:c0759adc
    Kernel panic - not syncing: Fatal exception in interrupt
    
    Arnaldo says:
    ====================
    Thanks! I'm to blame for this one, problem was introduced in:
    
    b0e380b
    
                    /*
                     *      Copy a block of the IP datagram.
                     */
    -               if (skb_copy_bits(skb, ptr, frag->h.raw, len))
    +               if (skb_copy_bits(skb, ptr, skb_transport_header(skb),
    len))
                            BUG();
                    left -= len;
    ====================
    
    Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
    Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. @grrtrr @gregkh

    DCCP: Fix DCCP GFP_KERNEL allocation in atomic context

    grrtrr authored gregkh committed
    This fixes the following bug reported in syslog:
    
    [ 4039.051658] BUG: sleeping function called from invalid context at /usr/src/davem-2.6/mm/slab.c:3032
    [ 4039.051668] in_atomic():1, irqs_disabled():0
    [ 4039.051670] INFO: lockdep is turned off.
    [ 4039.051674]  [<c0104c0f>] show_trace_log_lvl+0x1a/0x30
    [ 4039.051687]  [<c0104d4d>] show_trace+0x12/0x14
    [ 4039.051691]  [<c0104d65>] dump_stack+0x16/0x18
    [ 4039.051695]  [<c011371e>] __might_sleep+0xaf/0xbe
    [ 4039.051700]  [<c0157b66>] __kmalloc+0xb1/0xd0
    [ 4039.051706]  [<f090416f>] ccid2_hc_tx_alloc_seq+0x35/0xc3 [dccp_ccid2]
    [ 4039.051717]  [<f09048d6>] ccid2_hc_tx_packet_sent+0x27f/0x2d9 [dccp_ccid2]
    [ 4039.051723]  [<f085486b>] dccp_write_xmit+0x1eb/0x338 [dccp]
    [ 4039.051741]  [<f085603d>] dccp_sendmsg+0x113/0x18f [dccp]
    [ 4039.051750]  [<c03907fc>] inet_sendmsg+0x2e/0x4c
    [ 4039.051758]  [<c033a47d>] sock_aio_write+0xd5/0x107
    [ 4039.051766]  [<c015abc1>] do_sync_write+0xcd/0x11c
    [ 4039.051772]  [<c015b296>] vfs_write+0x118/0x11f
    [ 4039.051840]  [<c015b932>] sys_write+0x3d/0x64
    [ 4039.051845]  [<c0103e7c>] syscall_call+0x7/0xb
    [ 4039.051848]  =======================
    
    The problem was that GFP_KERNEL was used; fixed by using gfp_any().
    
    Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. @gregkh

    signalfd: make it group-wide, fix posix-timers scheduling

    Oleg Nesterov authored gregkh committed
    With this patch any thread can dequeue its own private signals via signalfd,
    even if it was created by another sub-thread.
    
    To do so, we pass "current" to dequeue_signal() if the caller is from the same
    thread group. This also fixes the scheduling of posix timers broken by the
    previous patch.
    
    If the caller doesn't belong to this thread group, we can't handle __SI_TIMER
    case properly anyway. Perhaps we should forbid the cross-process signalfd usage
    and convert ctx->tsk to ctx->sighand.
    
    Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Davide Libenzi <davidel@xmailserver.org>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Michael Kerrisk <mtk-manpages@gmx.net>
    Cc: Roland McGrath <roland@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @gregkh

    signalfd: fix interaction with posix-timers

    Oleg Nesterov authored gregkh committed
    dequeue_signal:
    
    	if (__SI_TIMER) {
    		spin_unlock(&tsk->sighand->siglock);
    		do_schedule_next_timer(info);
    		spin_lock(&tsk->sighand->siglock);
    	}
    
    Unless tsk == curent, this is absolutely unsafe: nothing prevents tsk from
    exiting. If signalfd was passed to another process, do_schedule_next_timer()
    is just wrong.
    
    Add yet another "tsk == current" check into dequeue_signal().
    
    This patch fixes an oopsable bug, but breaks the scheduling of posix timers
    if the shared __SI_TIMER signal was fetched via signalfd attached to another
    sub-thread. Mostly fixed by the next patch.
    
    Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Davide Libenzi <davidel@xmailserver.org>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Michael Kerrisk <mtk-manpages@gmx.net>
    Cc: Roland McGrath <roland@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. @gregkh

    i386: fix lazy mode vmalloc synchronization for paravirt

    Zachary Amsden authored gregkh committed
    Found this looping Ubuntu installs with VMI.
    
    If unlucky enough to hit a vmalloc sync fault during a lazy mode
    operation (from an IRQ handler for a module which was not yet populated
    in current page directory, or from inside copy_one_pte, which touches
    swap_map, and hit in an unused 4M region), the required PDE update would
    never get flushed, causing an infinite page fault loop.
    
    This bug affects any paravirt-ops backend which uses lazy updates, I
    believe that makes it a bug in Xen, VMI and lguest.  It only happens on
    LOWMEM kernels.
    
    
    Touching vmalloc memory in the middle of a lazy mode update can generate a
    kernel PDE update, which must be flushed immediately.  The fix is to leave
    lazy mode when doing a vmalloc sync.
    
    Signed-off-by: Zachary Amsden <zach@vmware.com>
    Cc: Andi Kleen <ak@suse.de>
    Cc: Jeremy Fitzhardinge <jeremy@goop.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  25. @gregkh

    uml: fix previous request size limit fix

    Jeff Dike authored gregkh committed
    The previous patch which limited the number of sectors in a single request
    to a COWed device was correct in concept, but the limit was implemented in
    the wrong place.
    
    By putting it in ubd_add, it covered the cases where the COWing was
    specified on the command line.  However, when the command line only has the
    COW file specified, the fact that it's a COW file isn't known until it's
    opened, so the limit is missed in these cases.
    
    This patch moves the sector limit from ubd_add to ubd_open_dev.
    
    Signed-off-by: Jeff Dike <jdike@linux.intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. @gregkh

    sky2: don't clear phy power bits

    Stephen Hemminger authored gregkh committed
    There are special PHY settings available on Yukon EC-U chip that
    should not get cleared. This should solve mysterious errors on some
    motherboards (like Gigabyte DS-3).
    
    Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. @herbertx @gregkh

    NET: Share correct feature code between bridging and bonding

    herbertx authored gregkh committed
    [NET]: Share correct feature code between bridging and bonding
    
    http://bugzilla.kernel.org/show_bug.cgi?id=8797 shows that the
    bonding driver may produce bogus combinations of the checksum
    flags and SG/TSO.
    
    For example, if you bond devices with NETIF_F_HW_CSUM and
    NETIF_F_IP_CSUM you'll end up with a bonding device that
    has neither flag set.  If both have TSO then this produces
    an illegal combination.
    
    The bridge device on the other hand has the correct code to
    deal with this.
    
    In fact, the same code can be used for both.  So this patch
    moves that logic into net/core/dev.c and uses it for both
    bonding and bridging.
    
    In the process I've made small adjustments such as only
    setting GSO_ROBUST if at least one constituent device
    supports it.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Acked-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  28. @gregkh

    ocfs2: Fix bad source start calculation during kernel writes

    Mark Fasheh authored gregkh committed
    [PATCH] ocfs2: Fix bad source start calculation during kernel writes
    
    For in-kernel writes ocfs2_get_write_source() should be starting the buffer
    at a page boundary as the math in ocfs2_map_and_write_user_data() will pad
    it back out to the correct write offset. Instead, we were passing the raw
    offset, which caused ocfs2_map_and_write_user_data() start too far into the
    buffer, resulting in corruptions from nfs client writes.
    
    Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commits on Aug 22, 2007
  1. @gregkh

    Linux 2.6.22.5

    gregkh authored
  2. @dwmw2 @gregkh

    JFFS2 locking regression fix.

    dwmw2 authored gregkh committed
    Commit a491486 introduced a locking
    problem in JFFS2 -- we up() the alloc_sem when we weren't previously
    holding it. This leads to all kinds of fun behaviour later.
    
    There was a _reason_ for the
    	if (1 /* alternative path needs testing */ ||
    which the above-mentioned commit removed :)
    
    Discovered and debugged by Giulio Fedel <giulio.fedel@andorsystems.com>
    
    Signed-off-by: David Woodhouse <dwmw2@infradead.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @gregkh

    i386: Fix double fault handler

    Chuck Ebbert authored gregkh committed
    The new percpu code has apparently broken the doublefault handler
    when CONFIG_DEBUG_SPINLOCK is set. Doublefault is handled by
    a hardware task, making the check
    
            SPIN_BUG_ON(lock->owner == current, lock, "recursion");
    
    fault because it uses the FS register to access the percpu data
    for current, and that register is zero in the new TSS. (The trace
    I saw was on 2.6.20 where it was GS, but it looks like this will
    still happen with FS on 2.6.22.)
    
    Initializing FS in the doublefault_tss should fix it.
    
    AK: Also fix broken ptr_ok() and turn printks into KERN_EMERG
    AK: And add a PANIC prefix to make clear the system will hang
    AK: (e.g. x86-64 will recover)
    
    Signed-off-by: Chuck Ebbert <cebbert@redhat.com>
    Signed-off-by: Andi Kleen <ak@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.