Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Jun 6, 2008
  1. @chriswright

    Linux 2.6.25.5

    chriswright authored
  2. @chriswright

    asn1: additional sanity checking during BER decoding (CVE-2008-1673)

    chriswright authored
    upstream commit: ddb2c43
    
    - Don't trust a length which is greater than the working buffer.
      An invalid length could cause overflow when calculating buffer size
      for decoding oid.
    
    - An oid length of zero is invalid and allows for an off-by-one error when
      decoding oid because the first subid actually encodes first 2 subids.
    
    - A primitive encoding may not have an indefinite length.
    
    Thanks to Wei Wang from McAfee for report.
    
    Cc: Steven French <sfrench@us.ibm.com>
    Cc: stable@kernel.org
    Acked-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commits on May 15, 2008
  1. @gregkh

    Linux 2.6.25.4

    gregkh authored
  2. @djbw @gregkh

    md: fix raid5 'repair' operations

    djbw authored gregkh committed
    commit c889441 upstream
    Date: Mon, 12 May 2008 14:02:12 -0700
    Subject: md: fix raid5 'repair' operations
    
    commit bd2ab67 "md: close a livelock window
    in handle_parity_checks5" introduced a bug in handling 'repair' operations.
    After a repair operation completes we clear the state bits tracking this
    operation.  However, they are cleared too early and this results in the code
    deciding to re-run the parity check operation.  Since we have done the repair
    in memory the second check does not find a mismatch and thus does not do a
    writeback.
    
    Test results:
    $ echo repair > /sys/block/md0/md/sync_action
    $ cat /sys/block/md0/md/mismatch_cnt
    51072
    $ echo repair > /sys/block/md0/md/sync_action
    $ cat /sys/block/md0/md/mismatch_cnt
    0
    
    (also fix incorrect indentation)
    
    Tested-by: George Spelvin <linux@horizon.com>
    Acked-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @gregkh

    rtc: rtc_time_to_tm: use unsigned arithmetic

    Maciej W. Rozycki authored gregkh committed
    commit 945185a upstream
    Date: Mon, 12 May 2008 14:02:24 -0700
    Subject: rtc: rtc_time_to_tm: use unsigned arithmetic
    
    The input argument to rtc_time_to_tm() is unsigned as well as are members of
    the output structure.  However signed arithmetic is used within for
    calculations leading to incorrect results for input values outside the signed
    positive range.  If this happens the time of day returned is out of range.
    
    Found the problem when fiddling with the RTC and the driver where year was set
    to an unexpectedly large value like 2070, e.g.:
    
    rtc0: setting system clock to 2070-01-01 1193046:71582832:26 UTC (3155760954)
    
    while it should be:
    
    rtc0: setting system clock to 2070-01-01 00:15:54 UTC (3155760954)
    
    Changing types to unsigned fixes the problem.
    
    [akpm@linux-foundation.org: remove old-fashioned `register' keyword]
    Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    Cc: David Brownell <david-b@pacbell.net>
    Cc: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @gregkh

    SCSI: aha152x: fix init suspiciously returned 1, it should follow 0/-…

    James Bottomley authored gregkh committed
    …E convention
    
    commit ad2fa42 upstream
    
    Reported-by: Frank de Jong <frapex@xs4all.nl>
    > [1.] One line summary of the problem:
    > linux-2.6.25.3, aha152x'->init suspiciously returned 1, it should
    > follow 0/-E convention. The module / driver works okay. Unloading the
    > module is impossible.
    
    The driver is apparently returning 0 on failure and 1 on success.
    That's a bit unfortunate.  Fix it by altering to -ENODEV and 0.
    
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @gregkh

    SCSI: aha152x: Fix oops on module removal

    James Bottomley authored gregkh committed
    commit 64976a0 upstream
    
    Reported-by: Frank de Jong <frapex@xs4all.nl>
    > after trying to unload the module:
    > BUG: unable to handle kernel paging request at 00100100
    > IP: [<fb9ff667>] :aha152x:aha152x_exit+0x47/0x6a
    > *pde = 00000000
    > Oops: 0000 [#1] PREEMPT SMP
    > Modules linked in: aha152x(-) w83781d hwmon_vid tun ne 8390 bonding
    > usb_storage snd_usb_audio snd_usb_lib snd_rawmidi pwc snd_seq_device
    > compat_ioctl32 snd_hwdep videodev v4l1_compat 3c59x mii intel_agp
    > agpgart snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd
    >
    > Pid: 2837, comm: rmmod Not tainted (2.6.25.3 #1)
    > EIP: 0060:[<fb9ff667>] EFLAGS: 00210212 CPU: 0
    > EIP is at aha152x_exit+0x47/0x6a [aha152x]
    > EAX: 00000001 EBX: 000ffdc4 ECX: f7c517a8 EDX: 00000001
    > ESI: 00000000 EDI: 00000003 EBP: e7880000 ESP: e7881f58
    >   DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
    > Process rmmod (pid: 2837, ti=e7880000 task=f27eb580 task.ti=e7880000)
    > Stack: fba03700 c01419d2 31616861 00783235 e795ee70 c0157709 b7f24000 e79ae000
    >         c0158271 ffffffff b7f25000 e79ae004 e795e370 b7f25000 e795e37c e795e370
    >         009ae000 fba03700 00000880 e7881fa8 00000000 bf93ec20 bf93ec20 c0102faa
    > Call Trace:
    >   [<c01419d2>] sys_delete_module+0x112/0x1a0
    >   [<c0157709>] remove_vma+0x39/0x50
    >   [<c0158271>] do_munmap+0x181/0x1f0
    >   [<c0102faa>] sysenter_past_esp+0x5f/0x85
    >   [<c0490000>] rsc_parse+0x0/0x3c0
    
    The problem is that the driver calls aha152x_release() under a
    list_for_each_entry().  Unfortunately, aha152x_release() deletes from
    the list in question.  Fix this by using list_for_each_entry_safe().
    
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @mikechristie @gregkh

    SCSI: libiscsi regression in 2.6.25: fix setting of recv timer

    mikechristie authored gregkh committed
    commit c8611f9 upstream
    
    If the ping tmo is longer than the recv tmo then we could miss a window
    where we were supposed to check the recv tmo. This happens because
    the ping code will set the next timeout for the ping timeout, and if the
    ping executes quickly there will be a long chunk of time before the
    timer wakes up again.
    
    This patch has the ping processing code kick off a recv
    tmo check when getting a nop in response to our ping.
    
    Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @mikechristie @gregkh

    SCSI: libiscsi regression in 2.6.25: fix nop timer handling

    mikechristie authored gregkh committed
    commit 4cf1043 upstream
    
    The following patch fixes a bug in the iscsi nop processing.
    The target sends iscsi nops to ping the initiator and the
    initiator has to send nops to reply and can send nops to
    ping the target.
    
    In 2.6.25 we moved the nop processing to the kernel to handle
    problems when the userspace daemon is not up, but the target
    is pinging us, and to handle when scsi commands timeout, but
    the transport may be the cause (we can send a nop to check
    the transport). When we added this code we added a bug where
    if the transport timer wakes at the exact same time we are supposed to check
    for a nop timeout we drop the session instead of checking the transport.
    
    This patch checks if a iscsi ping is outstanding and if the ping has
    timed out, to determine if we need to signal a connection problem.
    
    Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @gregkh

    SCSI: qla1280: Fix queue depth problem

    Jeremy Higdon authored gregkh committed
    commit af5741c upstream
    
    The qla1280 driver was ANDing the output value of mailbox register
    0 with (1 << target-number) to determine whether to enable queueing
    on the target in question.
    
    But mailbox register 0 has the status code for the mailbox command
    (in this case, Set Target Parameters).  Potential values are:
    /*
     * ISP mailbox command complete status codes
     */
    
    So clearly that is in error.  I can't think what the author of that
    line was looking for in a mailbox register, so I just eliminated the
    AND.  flag is used later in the function, and I think that the later
    usage was also wrong, though it was used to set values that aren't
    used.  Oh well, an overhaul of this driver is not what I want to do
    now -- just a bugfix.
    
    After the fix, I found that my disks were getting a queue depth of
    255, which is far too many.  Most SCSI disks are limited to 32 or
    64.  In any case, there's no point, queueing up a bunch of commands
    to the adapter that will just result in queue full or starve other
    targets from being issued commands due to running out of internal
    memory.  So I dropped default queue depth to 32 (from which 1 is
    subtracted elsewhere, giving net of 31).
    
    I tested with a Seagate ST336753LC, and results look good, so
    I'm satisfied with this patch.
    
    Signed-off-by: Jeremy Higdon <jeremy@sgi.com>
    Acked-by: Jes Sorensen <jes@sgi.com>
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @gregkh

    r8169: fix oops in r8169_get_mac_version

    Ivan Vecera authored gregkh committed
    commit 21e197f upstream.
    
    r8169_get_mac_version crashes when it meets an unknown MAC
    due to tp->pci_dev not being set. Initialize it early.
    
    Signed-off-by: Ivan Vecera <ivecera@redhat.com>
    Acked-by: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @gregkh

    r8169: fix past rtl_chip_info array size for unknown chipsets

    Roel Kluin authored gregkh committed
    commit cee60c3 upstream.
    
    'i' is unsigned.
    
    Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
    Acked-by: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @lchiquitto @gregkh

    USB: airprime: unlock mutex instead of trying to lock it again

    lchiquitto authored gregkh committed
    commit 21ae1dd upstream
    
    The following patch fixes a [probable] copy & paste mistake in
    airprime.c. Instead of unlocking an acquired mutex, the actual
    code tries to lock it again.
    
    Signed-off-by: Leonardo Chiquitto <lchiquitto@novell.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @davem330 @gregkh

    sparc32: Don't twiddle PT_DTRACE in exec.

    davem330 authored gregkh committed
    [ Upstream commit: c07c605 ]
    
    That bit isn't used on this platform.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @davem330 @gregkh

    sparc: Fix debugger syscall restart interactions.

    davem330 authored gregkh committed
    [ This is a 2.6.25 backport of upstream changeset
      28e6103 with sparc32 build
      fixes from Robert Reif ]
    
    So, forever, we've had this ptrace_signal_deliver implementation
    which tries to handle all of the nasties that can occur when the
    debugger looks at a process about to take a signal.  It's meant
    to address all of these issues inside of the kernel so that the
    debugger need not be mindful of such things.
    
    Problem is, this doesn't work.
    
    The idea was that we should do the syscall restart business first, so
    that the debugger captures that state.  Otherwise, if the debugger for
    example saves the child's state, makes the child execute something
    else, then restores the saved state, we won't handle the syscall
    restart properly because we lose the "we're in a syscall" state.
    
    The code here worked for most cases, but if the debugger actually
    passes the signal through to the child unaltered, it's possible that
    we would do a syscall restart when we shouldn't have.
    
    In particular this breaks the case of debugging a process under a gdb
    which is being debugged by yet another gdb.  gdb uses sigsuspend
    to wait for SIGCHLD of the inferior, but if gdb itself is being
    debugged by a top-level gdb we get a ptrace_stop().  The top-level gdb
    does a PTRACE_CONT with SIGCHLD to let the inferior gdb see the
    signal.  But ptrace_signal_deliver() assumed the debugger would cancel
    out the signal and therefore did a syscall restart, because the return
    error was ERESTARTNOHAND.
    
    Fix this by simply making ptrace_signal_deliver() a nop, and providing
    a way for the debugger to control system call restarting properly:
    
    1) Report a "in syscall" software bit in regs->{tstate,psr}.
       It is set early on in trap entry to a system call and is fully
       visible to the debugger via ptrace() and regsets.
    
    2) Test this bit right before doing a syscall restart.  We have
       to do a final recheck right after get_signal_to_deliver() in
       case the debugger cleared the bit during ptrace_stop().
    
    3) Clear the bit in trap return so we don't accidently try to set
       that bit in the real register.
    
    As a result we also get a ptrace_{is,clear}_syscall() for sparc32 just
    like sparc64 has.
    
    M68K has this same exact bug, and is now the only other user of the
    ptrace_signal_deliver hook.  It needs to be fixed in the same exact
    way as sparc.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @davem330 @gregkh

    sparc: Fix mremap address range validation.

    davem330 authored gregkh committed
    Just like mmap, we need to validate address ranges regardless
    of MAP_FIXED.
    
    sparc{,64}_mmap_check()'s flag argument is unused, remove.
    
    Based upon a report and preliminary patch by
    Jan Lieskovsky <jlieskov@redhat.com>
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @davem330 @gregkh

    sparc: Fix ptrace() detach.

    davem330 authored gregkh committed
    [ Upstream commit: 986bef8 ]
    
    Forever we had a PTRACE_SUNOS_DETACH which was unconditionally
    recognized, regardless of the personality of the process.
    
    Unfortunately, this value is what ended up in the GLIBC sys/ptrace.h
    header file on sparc as PTRACE_DETACH and PT_DETACH.
    
    So continue to recognize this old value.  Luckily, it doesn't conflict
    with anything we actually care about.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @gregkh

    i2c-piix4: Blacklist two mainboards

    Jean Delvare authored gregkh committed
    commit c2fc54f upstream
    
    We had a report that running sensors-detect on a Sapphire AM2RD790
    motherbord killed the CPU. While the exact cause is still unknown,
    I'd rather play it safe and prevent any access to the SMBus on that
    machine by not letting the i2c-piix4 driver attach to the SMBus host
    device on that machine. Also blacklist a similar board made by DFI.
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @svaidy @gregkh

    x86: sysfs cpu?/topology is empty in 2.6.25 (32-bit Intel system)

    svaidy authored gregkh committed
    commit 5c3a121 upstream
    
    System topology on intel based system needs to be exported
    for non-numa case as well.
    
    All parts of asm-i386/topology.h has come under
    #ifdef CONFIG_NUMA after the merge to asm-x86/topology.h
    
    /sys/devices/system/cpu/cpu?/topology/* is populated based on
    ENABLE_TOPO_DEFINES
    
    The sysfs cpu topology is not being populated on my dual socket
    dual core xeon 5160 processor based (x86 32 bit) system.
    
    CONFIG_NUMA is not set in my case yet the topology is relevant
    and useful.
    
    irqbalance daemon application depends on topology to build the
    cpus and package list and it fails on Fedora9 beta since the
    sysfs topology was not being populated in the 2.6.25 kernel.
    
    I am not sure if it was intentional to not define ENABLE_TOPO_DEFINES
    for non-numa systems.
    
    This fix has been tested on the above mentioned dual core, dual socket
    system.
    
    Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @htejun @gregkh

    ata_piix: verify SIDPR access before enabling it

    htejun authored gregkh committed
    commit cb6716c upstream
    
    On certain configurations (certain macbooks), even though all the
    conditions for SIDPR access described in the datasheet are met,
    actually reading those registers just returns 0 and have no effect on
    write.  Verify SIDPR is actually working before enabling it.
    
    This is reported by Ryan Roth in bz#10512.
    
    Signed-off-by: Tejun Heo <htejun@gmail.com>
    Cc: Ryan Roth <ryan.roth@ch2m.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @gregkh

    {nfnetlink, ip, ip6}_queue: fix skb_over_panic when enlarging packets

    Arnaud Ebalard authored gregkh committed
    [NETFILTER]: {nfnetlink,ip,ip6}_queue: fix skb_over_panic when enlarging packets
    
    From: Arnaud Ebalard <arno@natisbad.org>
    
    Upstream commit 9a732ed:
    
    While reinjecting *bigger* modified versions of IPv6 packets using
    libnetfilter_queue, things work fine on a 2.6.24 kernel (2.6.22 too)
    but I get the following on recents kernels (2.6.25, trace below is
    against today's net-2.6 git tree):
    
    skb_over_panic: text:c04fddb0 len:696 put:632 head:f7592c00 data:f7592c00 tail:0xf7592eb8 end:0xf7592e80 dev:eth0
    ------------[ cut here ]------------
    invalid opcode: 0000 [#1] PREEMPT
    Process sendd (pid: 3657, ti=f6014000 task=f77c31d0 task.ti=f6014000)
    Stack: c071e638 c04fddb0 000002b8 00000278 f7592c00 f7592c00 f7592eb8 f7592e80
           f763c000 f6bc5200 f7592c40 f6015c34 c04cdbfc f6bc5200 00000278 f6015c60
           c04fddb0 00000020 f72a10c0 f751b420 00000001 0000000a 000002b8 c065582c
    Call Trace:
     [<c04fddb0>] ? nfqnl_recv_verdict+0x1c0/0x2e0
     [<c04cdbfc>] ? skb_put+0x3c/0x40
     [<c04fddb0>] ? nfqnl_recv_verdict+0x1c0/0x2e0
     [<c04fd115>] ? nfnetlink_rcv_msg+0xf5/0x160
     [<c04fd03e>] ? nfnetlink_rcv_msg+0x1e/0x160
     [<c04fd020>] ? nfnetlink_rcv_msg+0x0/0x160
     [<c04f8ed7>] ? netlink_rcv_skb+0x77/0xa0
     [<c04fcefc>] ? nfnetlink_rcv+0x1c/0x30
     [<c04f8c73>] ? netlink_unicast+0x243/0x2b0
     [<c04cfaba>] ? memcpy_fromiovec+0x4a/0x70
     [<c04f9406>] ? netlink_sendmsg+0x1c6/0x270
     [<c04c8244>] ? sock_sendmsg+0xc4/0xf0
     [<c011970d>] ? set_next_entity+0x1d/0x50
     [<c0133a80>] ? autoremove_wake_function+0x0/0x40
     [<c0118f9e>] ? __wake_up_common+0x3e/0x70
     [<c0342fbf>] ? n_tty_receive_buf+0x34f/0x1280
     [<c011d308>] ? __wake_up+0x68/0x70
     [<c02cea47>] ? copy_from_user+0x37/0x70
     [<c04cfd7c>] ? verify_iovec+0x2c/0x90
     [<c04c837a>] ? sys_sendmsg+0x10a/0x230
     [<c011967a>] ? __dequeue_entity+0x2a/0xa0
     [<c011970d>] ? set_next_entity+0x1d/0x50
     [<c0345397>] ? pty_write+0x47/0x60
     [<c033d59b>] ? tty_default_put_char+0x1b/0x20
     [<c011d2e9>] ? __wake_up+0x49/0x70
     [<c033df99>] ? tty_ldisc_deref+0x39/0x90
     [<c033ff20>] ? tty_write+0x1a0/0x1b0
     [<c04c93af>] ? sys_socketcall+0x7f/0x260
     [<c0102ff9>] ? sysenter_past_esp+0x6a/0x91
     [<c05f0000>] ? snd_intel8x0m_probe+0x270/0x6e0
     =======================
    Code: 00 00 89 5c 24 14 8b 98 9c 00 00 00 89 54 24 0c 89 5c 24 10 8b 40 50 89 4c 24 04 c7 04 24 38 e6 71 c0 89 44 24 08 e8 c4 46 c5 ff <0f> 0b eb fe 55 89 e5 56 89 d6 53 89 c3 83 ec 0c 8b 40 50 39 d0
    EIP: [<c04ccdfc>] skb_over_panic+0x5c/0x60 SS:ESP 0068:f6015bf8
    
    Looking at the code, I ended up in nfq_mangle() function (called by
    nfqnl_recv_verdict()) which performs a call to skb_copy_expand() due to
    the increased size of data passed to the function. AFAICT, it should ask
    for 'diff' instead of 'diff - skb_tailroom(e->skb)'. Because the
    resulting sk_buff has not enough space to support the skb_put(skb, diff)
    call a few lines later, this results in the call to skb_over_panic().
    
    The patch below asks for allocation of a copy with enough space for
    mangled packet and the same amount of headroom as old sk_buff. While
    looking at how the regression appeared (e2b58a6), I noticed the same
    pattern in ipq_mangle_ipv6() and ipq_mangle_ipv4(). The patch corrects
    those locations too.
    
    Tested with bigger reinjected IPv6 packets (nfqnl_mangle() path), things
    are ok (2.6.25 and today's net-2.6 git tree).
    
    Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. @gregkh

    nf_conntrack: padding breaks conntrack hash on ARM

    Philip Craig authored gregkh committed
    [NETFILTER]: nf_conntrack: padding breaks conntrack hash on ARM
    
    Upstream commit 443a70d:
    
    commit 0794935 "[NETFILTER]: nf_conntrack: optimize hash_conntrack()"
    results in ARM platforms hashing uninitialised padding.  This padding
    doesn't exist on other architectures.
    
    Fix this by replacing NF_CT_TUPLE_U_BLANK() with memset() to ensure
    everything is initialised.  There were only 4 bytes that
    NF_CT_TUPLE_U_BLANK() wasn't clearing anyway (or 12 bytes on ARM).
    
    Signed-off-by: Philip Craig <philipc@snapgear.com>
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. @gregkh

    x86: use defconfigs from x86/configs/*

    Sam Ravnborg authored gregkh committed
    commit b9b39bf upstream
    
    x86: use defconfigs from x86/configs/*
    
    Daniel Drake <dsd@gentoo.org> reported:
    
    In 2.6.23, if you unpacked a kernel source tarball and then
    ran "make menuconfig" you'd be presented with this message:
        # using defaults found in arch/i386/defconfig
    
    and the default options would be set.
    
    The same thing in 2.6.24 does not give you any "using defaults" message, and
    the default config options within menuconfig are rather blank (e.g. no PCI
    support). You can work around this by explicitly running "make defconfig"
    before menuconfig, but it would be nice to have the behaviour the way it was
    for 2.6.23 (and the way it still is for other archs).
    
    Fixed by adding a x86 specific defconfig list to Kconfig.
    
    Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=10470
    
    Tested-by: Daniel Drake <dsd@gentoo.org>
    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. @gregkh

    can: Fix can_send() handling on dev_queue_xmit() failures

    Oliver Hartkopp authored gregkh committed
    [ Upstream commit: c2ab7ac ]
    
    The tx packet counting and the local loopback of CAN frames should
    only happen in the case that the CAN frame has been enqueued to the
    netdevice tx queue successfully.
    
    Thanks to Andre Naujoks <nautsch@gmail.com> for reporting this issue.
    
    Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
    Signed-off-by: Urs Thuermann <urs@isnogud.escape.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @chriswright @gregkh

    dccp: return -EINVAL on invalid feature length

    chriswright authored gregkh committed
    [ Upstream commit: 1944317 ]
    
    dccp_feat_change() validates length and on error is returning 1.
    This happens to work since call chain is checking for 0 == success,
    but this is returned to userspace, so make it a real error value.
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. @gregkh

    ipvs: fix oops in backup for fwmark conn templates

    Julian Anastasov authored gregkh committed
    [ Upstream commit: 2ad17de ]
    
    	Fixes bug http://bugzilla.kernel.org/show_bug.cgi?id=10556
    where conn templates with protocol=IPPROTO_IP can oops backup box.
    
            Result from ip_vs_proto_get() should be checked because
    protocol value can be invalid or unsupported in backup. But
    for valid message we should not fail for templates which use
    IPPROTO_IP. Also, add checks to validate message limits and
    connection state. Show state NONE for templates using IPPROTO_IP.
    
    Fix tested and confirmed by L0op8ack <l0op8ack@hotmail.com>
    
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  25. @kaber @gregkh

    macvlan: Fix memleak on device removal/crash on module removal

    kaber authored gregkh committed
    [ Upstream commit: 7312096 ]
    
    As noticed by Ben Greear, macvlan crashes the kernel when unloading the
    module. The reason is that it tries to clean up the macvlan_port pointer
    on the macvlan device itself instead of the underlying device. A non-NULL
    pointer is taken as indication that the macvlan_handle_frame_hook is
    valid, when receiving the next packet on the underlying device it tries
    to call the NULL hook and crashes.
    
    Clean up the macvlan_port on the correct device to fix this.
    
    Signed-off-by; Patrick McHardy <kaber@trash.net>
    Tested-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. @gregkh

    sch_htb: remove from event queue in htb_parent_to_leaf()

    Jarek Poplawski authored gregkh committed
    [ Upstream commit: 3ba08b0 ]
    
    There is lack of removing a class from the event queue while changing
    from parent to leaf which can cause corruption of this rb tree. This
    patch fixes a bug introduced by my patch: "sch_htb: turn intermediate
    classes into leaves" commit: 160d5e1.
    
    Many thanks to Jan 'yanek' Bortl for finding a way to reproduce this
    rare bug and narrowing the test case, which made possible proper
    diagnosing.
    
    This patch is recommended for all kernels starting from 2.6.20.
    
    Reported-and-tested-by: Jan 'yanek' Bortl <yanek@ya.bofh.cz>
    Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. @davem330 @gregkh

    serial: Fix sparc driver name strings.

    davem330 authored gregkh committed
    [ Upstream commit: b53e5216e5f73330bffae93b42dceb94e361f4c0 ]
    
    They were all "serial" so if multiple of these drivers registered,
    we'd trigger sysfs directory creation errors:
    
    [    1.695793] proc_dir_entry 'serial' already registered
    [    1.695839] Call Trace:
    [    1.831891]  [00000000004f2534] create_proc_entry+0x7c/0x98
    [    1.833608]  [00000000004f3a58] proc_tty_register_driver+0x40/0x70
    [    1.833663]  [0000000000594700] tty_register_driver+0x1fc/0x208
    [    1.835371]  [00000000005aade4] uart_register_driver+0x134/0x16c
    [    1.841762]  [00000000005ac274] sunserial_register_minors+0x34/0x68
    [    1.841818]  [00000000007db2a4] sunsu_init+0xf8/0x150
    [    1.867697]  [00000000007c62a4] kernel_init+0x190/0x330
    [    1.939147]  [0000000000426cf8] kernel_thread+0x38/0x48
    [    1.939198]  [00000000006a0d90] rest_init+0x18/0x5c
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  28. @davem330 @gregkh

    SPARC64: Fix args to 64-bit sys_semctl() via sys_ipc().

    davem330 authored gregkh committed
    [ Upstream commit: 020cfb0 ]
    
    Second and third arguments were swapped for whatever reason.
    
    Reported by Tom Callaway.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  29. @davem330 @gregkh

    sparc64: Fix wedged irq regression.

    davem330 authored gregkh committed
    [ Upstream commit: 92aa3573c9cd58fe0bcd1c52c9fd8f5708785917 ]
    
    Kernel bugzilla 10273
    
    As reported by Jos van der Ende, ever since commit
    5a606b7 ("[SPARC64]: Do not ACK an
    INO if it is disabled or inprogress.") sun4u interrupts
    can get stuck.
    
    What this changset did was add the following conditional to
    the various IRQ chip ->enable() handlers on sparc64:
    
    	if (unlikely(desc->status & (IRQ_DISABLED|IRQ_INPROGRESS)))
    		return;
    
    which is correct, however it means that special care is needed
    in the ->enable() method.
    
    Specifically we must put the interrupt into IDLE state during
    an enable, or else it might never be sent out again.
    
    Setting the INO interrupt state to IDLE resets the state machine,
    the interrupt input to the INO is retested by the hardware, and
    if an interrupt is being signalled by the device, the INO
    moves back into TRANSMIT state, and an interrupt vector is sent
    to the cpu.
    
    The two sun4v IRQ chip handlers were already doing this properly,
    only sun4u got it wrong.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  30. @davem330 @gregkh

    sparc64: Stop creating dummy root PCI host controller devices.

    davem330 authored gregkh committed
    [ Upstream commit: 86d8337618e69573b5ccd3553f800944e843cae7 ]
    
    It just creates confusion, errors, and bugs.
    
    For one thing, this can cause dup sysfs or procfs nodes to get
    created:
    
    [    1.198015] proc_dir_entry '00.0' already registered
    [    1.198036] Call Trace:
    [    1.198052]  [00000000004f2534] create_proc_entry+0x7c/0x98
    [    1.198092]  [00000000005719e4] pci_proc_attach_device+0xa4/0xd4
    [    1.198126]  [00000000007d991c] pci_proc_init+0x64/0x88
    [    1.198158]  [00000000007c62a4] kernel_init+0x190/0x330
    [    1.198183]  [0000000000426cf8] kernel_thread+0x38/0x48
    [    1.198210]  [00000000006a0d90] rest_init+0x18/0x5c
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  31. @davem330 @gregkh

    sparc: Fix fork/clone/vfork system call restart.

    davem330 authored gregkh committed
    [ Upstream commit: 1e38c12 ]
    
    We clobber %i1 as well as %i0 for these system calls,
    because they give two return values.
    
    Therefore, on error, we have to restore %i1 properly
    or else the restart explodes since it uses the wrong
    arguments.
    
    This fixes glibc's nptl/tst-eintr1.c testcase.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  32. @davem330 @gregkh

    sparc: Fix SA_ONSTACK signal handling.

    davem330 authored gregkh committed
    [ Upstream commit: dc5dc7e ]
    
    We need to be more liberal about the alignment of the buffer given to
    us by sigaltstack().  The user should not need to be mindful of all of
    the alignment constraints we have for the stack frame.
    
    This mirrors how we handle this situation in clone() as well.
    
    Also, we align the stack even in non-SA_ONSTACK cases so that signals
    due to bad stack alignment can be delivered properly.  This makes such
    errors easier to debug and recover from.
    
    Finally, add the sanity check x86 has to make sure we won't overflow
    the signal stack.
    
    This fixes glibc testcases nptl/tst-cancel20.c and
    nptl/tst-cancelx20.c
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  33. @IOBYTE @gregkh

    sparc: sunzilog uart order

    IOBYTE authored gregkh committed
    [ Upstream commit: 227739b ]
    
    I have a sparcstation 20 clone with a lot of on board serial ports.
    The serial core code assumes that uarts are assigned contiguously
    and that may not be the case when there are multiple zs devices
    present.  This patch insures that uart chips are placed in front of
    keyboard/mouse chips in the port table.
    
    ffd37420: ttyS0 at MMIO 0xf1100000 (irq = 44) is a zs (ESCC)
    Console: ttyS0 (SunZilog zs0)
    console [ttyS0] enabled
    ffd37420: ttyS1 at MMIO 0xf1100004 (irq = 44) is a zs (ESCC)
    ffd37500: Keyboard at MMIO 0xf1000000 (irq = 44) is a zs
    ffd37500: Mouse at MMIO 0xf1000004 (irq = 44) is a zs
    ffd3c5c0: ttyS2 at MMIO 0xf1100008 (irq = 44) is a zs (ESCC)
    ffd3c5c0: ttyS3 at MMIO 0xf110000c (irq = 44) is a zs (ESCC)
    ffd3c6a0: ttyS4 at MMIO 0xf1100010 (irq = 44) is a zs (ESCC)
    ffd3c6a0: ttyS5 at MMIO 0xf1100014 (irq = 44) is a zs (ESCC)
    ffd3c780: ttyS6 at MMIO 0xf1100018 (irq = 44) is a zs (ESCC)
    ffd3c780: ttyS7 at MMIO 0xf110001c (irq = 44) is a zs (ESCC)
    
    Signed-off-by: Robert Reif <reif@earthlink.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.