Skip to content
Commits on Mar 23, 2012
  1. @gregkh

    Linux 3.0.26

    gregkh committed Mar 23, 2012
  2. @ozbenh @gregkh

    powerpc/pmac: Fix SMP kernels on pre-core99 UP machines

    commit 78c5c68 upstream.
    The code for "powersurge" SMP would kick in and cause a crash
    at boot due to the lack of a NULL test.
    Signed-off-by: Benjamin Herrenschmidt <>
    Signed-off-by: Jeremy Kerr <>
    Reported-by: Adam Conrad <>
    Tested-by: Adam Conrad <>
    Signed-off-by: Greg Kroah-Hartman <>
    ozbenh committed with gregkh Dec 9, 2011
  3. @sgruszka @gregkh

    iwl3945: fix possible il->txq NULL pointer dereference in delayed works

    commit 210787e upstream.
    On il3945_down procedure we free tx queue data and nullify il->txq
    pointer. After that we drop mutex and then cancel delayed works. There
    is possibility, that after drooping mutex and before the cancel, some
    delayed work will start and crash while trying to send commands to
    the device. For example, here is reported crash in
    Patch fix problem by adding il->txq check on works that send commands,
    hence utilize tx queue.
    Reported-by: Clemens Eisserer <>
    Signed-off-by: Stanislaw Gruszka <>
    Signed-off-by: John W. Linville <>
    sgruszka committed with gregkh Mar 8, 2012
  4. @gregkh

    ipv6: Don't dev_hold(dev) in ip6_mc_find_dev_rcu.

    [ Upstream commit c577923 ]
    ip6_mc_find_dev_rcu() is called with rcu_read_lock(), so don't
    need to dev_hold().
    With dev_hold(), not corresponding dev_put(), will lead to leak.
    [ bug introduced in 96b52e6 (ipv6: mcast: RCU conversions) ]
    Signed-off-by: RongQing.Li <>
    Acked-by: Eric Dumazet <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    RongQing.Li committed with gregkh Mar 15, 2012
  5. @gregkh

    tcp: fix syncookie regression

    [ Upstream commit dfd25ff ]
    commit ea4fc0d (ipv4: Don't use rt->rt_{src,dst} in ip_queue_xmit())
    added a serious regression on synflood handling.
    Simon Kirby discovered a successful connection was delayed by 20 seconds
    before being responsive.
    In my tests, I discovered that xmit frames were lost, and needed ~4
    retransmits and a socket dst rebuild before being really sent.
    In case of syncookie initiated connection, we use a different path to
    initialize the socket dst, and inet->cork.fl.u.ip4 is left cleared.
    As ip_queue_xmit() now depends on inet flow being setup, fix this by
    copying the temp flowi4 we use in cookie_v4_check().
    Reported-by: Simon Kirby <>
    Bisected-by: Simon Kirby <>
    Signed-off-by: Eric Dumazet <>
    Tested-by: Eric Dumazet <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Eric Dumazet committed with gregkh Mar 10, 2012
  6. @antonblanchard @gregkh

    perf tools: Incorrect use of snprintf results in SEGV

    commit b832796 upstream.
    I have a workload where perf top scribbles over the stack and we SEGV.
    What makes it interesting is that an snprintf is causing this.
    The workload is a c++ gem that has method names over 3000 characters
    long, but snprintf is designed to avoid overrunning buffers. So what
    went wrong?
    The problem is we assume snprintf returns the number of characters
        ret += repsep_snprintf(bf + ret, size - ret, "[%c] ", self->level);
        ret += repsep_snprintf(bf + ret, size - ret, "%s", self->ms.sym->name);
    Unfortunately this is not how snprintf works. snprintf returns the
    number of characters that would have been written if there was enough
    space. In the above case, if the first snprintf returns a value larger
    than size, we pass a negative size into the second snprintf and happily
    scribble over the stack. If you have 3000 character c++ methods thats a
    lot of stack to trample.
    This patch fixes repsep_snprintf by clamping the value at size - 1 which
    is the maximum snprintf can write before adding the NULL terminator.
    I get the sinking feeling that there are a lot of other uses of snprintf
    that have this same bug, we should audit them all.
    Cc: David Ahern <>
    Cc: Eric B Munson <>
    Cc: Frederic Weisbecker <>
    Cc: Ingo Molnar <>
    Cc: Paul Mackerras <>
    Cc: Peter Zijlstra <>
    Cc: Yanmin Zhang <>
    Signed-off-by: Anton Blanchard <>
    Signed-off-by: Arnaldo Carvalho de Melo <>
    Signed-off-by: Greg Kroah-Hartman <>
    antonblanchard committed with gregkh Mar 7, 2012
  7. @antonblanchard @gregkh

    afs: Remote abort can cause BUG in rxrpc code

    commit c017386 upstream.
    When writing files to afs I sometimes hit a BUG:
    kernel BUG at fs/afs/rxrpc.c:179!
    With a backtrace of:
    The cause is:
    Looking at a tcpdump of the session the abort happens because we
    are exceeding our disk quota:
    	rx abort fs reply store-data error diskquota exceeded (32)
    So the abort error is valid. We hit the BUG because we haven't
    freed all the resources for the call.
    By freeing any skbs in call->rx_queue before calling afs_free_call
    we avoid hitting leaking memory and avoid hitting the BUG.
    Signed-off-by: Anton Blanchard <>
    Signed-off-by: David Howells <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    antonblanchard committed with gregkh Mar 16, 2012
  8. @antonblanchard @gregkh

    afs: Read of file returns EBADMSG

    commit 2c724fb upstream.
    A read of a large file on an afs mount failed:
    # cat junk.file > /dev/null
    cat: junk.file: Bad message
    Looking at the trace, call->offset wrapped since it is only an
    unsigned short. In afs_extract_data:
            _enter("{%u},{%zu},%d,,%zu", call->offset, len, last, count);
            if (call->offset < count) {
                    if (last) {
                            _leave(" = -EBADMSG [%d < %zu]", call->offset, count);
                            return -EBADMSG;
    Which matches the trace:
    [cat   ] ==> afs_extract_data({65132},{524},1,,65536)
    [cat   ] <== afs_extract_data() = -EBADMSG [0 < 65536]
    call->offset went from 65132 to 0. Fix this by making call->offset an
    unsigned int.
    Signed-off-by: Anton Blanchard <>
    Signed-off-by: David Howells <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    antonblanchard committed with gregkh Mar 16, 2012
  9. @konis @gregkh

    nilfs2: fix NULL pointer dereference in nilfs_load_super_block()

    commit d7178c7 upstream.
    According to the report from Slicky Devil, nilfs caused kernel oops at
    nilfs_load_super_block function during mount after he shrank the
    partition without resizing the filesystem:
     BUG: unable to handle kernel NULL pointer dereference at 00000048
     IP: [<d0d7a08e>] nilfs_load_super_block+0x17e/0x280 [nilfs2]
     *pde = 00000000
     Oops: 0000 [#1] PREEMPT SMP
     Call Trace:
      [<d0d7a87b>] init_nilfs+0x4b/0x2e0 [nilfs2]
      [<d0d6f707>] nilfs_mount+0x447/0x5b0 [nilfs2]
      [<c0226636>] mount_fs+0x36/0x180
      [<c023d961>] vfs_kern_mount+0x51/0xa0
      [<c023ddae>] do_kern_mount+0x3e/0xe0
      [<c023f189>] do_mount+0x169/0x700
      [<c023fa9b>] sys_mount+0x6b/0xa0
      [<c04abd1f>] sysenter_do_call+0x12/0x28
     Code: 53 18 8b 43 20 89 4b 18 8b 4b 24 89 53 1c 89 43 24 89 4b 20 8b 43
     20 c7 43 2c 00 00 00 00 23 75 e8 8b 50 68 89 53 28 8b 54 b3 20 <8b> 72
     48 8b 7a 4c 8b 55 08 89 b3 84 00 00 00 89 bb 88 00 00 00
     EIP: [<d0d7a08e>] nilfs_load_super_block+0x17e/0x280 [nilfs2] SS:ESP 0068:ca9bbdcc
     CR2: 0000000000000048
    This turned out due to a defect in an error path which runs if the
    calculated location of the secondary super block was invalid.
    This patch fixes it and eliminates the reported oops.
    Reported-by: Slicky Devil <>
    Signed-off-by: Ryusuke Konishi <>
    Tested-by: Slicky Devil <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    konis committed with gregkh Mar 16, 2012
Commits on Mar 19, 2012
  1. @gregkh

    Linux 3.0.25

    gregkh committed Mar 19, 2012
  2. @gregkh

    i2c-algo-bit: Fix spurious SCL timeouts under heavy load

    commit 8ee161c upstream.
    When the system is under heavy load, there can be a significant delay
    between the getscl() and time_after() calls inside sclhi(). That delay
    may cause the time_after() check to trigger after SCL has gone high,
    causing sclhi() to return -ETIMEDOUT.
    To fix the problem, double check that SCL is still low after the
    timeout has been reached, before deciding to return -ETIMEDOUT.
    Signed-off-by: Ville Syrjala <>
    Signed-off-by: Jean Delvare <>
    Signed-off-by: Greg Kroah-Hartman <>
    Ville Syrjala committed with gregkh Mar 15, 2012
  3. @groeck @gregkh

    hwmon: (w83627ehf) Fix memory leak in probe function

    commit 32260d9 upstream.
    The driver probe function leaked memory if creating the cpu0_vid attribute file
    failed. Fix by converting the driver to use devm_kzalloc.
    Signed-off-by: Guenter Roeck <>
    Acked-by: Jean Delvare <>
    Signed-off-by: Greg Kroah-Hartman <>
    groeck committed with gregkh Mar 12, 2012
  4. @groeck @gregkh

    hwmon: (w83627ehf) Fix writing into fan_stop_time for NCT6775F/NCT6776F

    commit 33fa9b6 upstream.
    NCT6775F and NCT6776F have their own set of registers for FAN_STOP_TIME. The
    correct registers were used to read FAN_STOP_TIME, but writes used the wrong
    registers. Fix it.
    Signed-off-by: Guenter Roeck <>
    Acked-by: Jean Delvare <>
    Signed-off-by: Greg Kroah-Hartman <>
    groeck committed with gregkh Mar 12, 2012
  5. @gregkh

    compat: Re-add missing asm/compat.h include to fix compile breakage o…

    …n s390
    For 3.0 stable kernel the backport of 048cd4e
    "compat: fix compile breakage on s390" breaks compilation...
    Re-add a single #include <asm/compat.h> in order to fix this.
    This patch is _not_ necessary for upstream, only for stable kernels
    which include the "build fix" mentioned above.
    One fix for arch/s390/kernel/setup.c was already sent and applied. But
    we need a similar patch for drivers/s390/char/fs3270.c.
    Signed-off-by: Jiri Slaby <>
    Signed-off-by: Greg Kroah-Hartman <>
    Jiri Slaby committed with gregkh Mar 5, 2012
  6. @davem330 @gregkh

    sparc32: Add -Av8 to assembler command line.

    commit e0adb99 upstream.
    Newer version of binutils are more strict about specifying the
    correct options to enable certain classes of instructions.
    The sparc32 build is done for v7 in order to support sun4c systems
    which lack hardware integer multiply and divide instructions.
    So we have to pass -Av8 when building the assembler routines that
    use these instructions and get patched into the kernel when we find
    out that we have a v8 capable cpu.
    Reported-by: Paul Gortmaker <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    davem330 committed with gregkh Mar 13, 2012
  7. @gregkh

    sfc: Fix assignment of ip_summed for pre-allocated skbs

    commit ff3bc1e upstream.
    When pre-allocating skbs for received packets, we set ip_summed =
    CHECKSUM_UNNCESSARY.  We used to change it back to CHECKSUM_NONE when
    the received packet had an incorrect checksum or unhandled protocol.
    Commit bc8acf2 ('drivers/net: avoid
    some skb->ip_summed initializations') mistakenly replaced the latter
    assignment with a DEBUG-only assertion that ip_summed ==
    CHECKSUM_NONE.  This assertion is always false, but it seems no-one
    has exercised this code path in a DEBUG build.
    Fix this by moving our assignment of CHECKSUM_UNNECESSARY into
    Signed-off-by: Ben Hutchings <>
    Signed-off-by: Greg Kroah-Hartman <>
    Ben Hutchings committed with gregkh Feb 25, 2012
  8. @gregkh

    Block: use a freezable workqueue for disk-event polling

    commit 62d3c54 upstream.
    This patch (as1519) fixes a bug in the block layer's disk-events
    polling.  The polling is done by a work routine queued on the
    system_nrt_wq workqueue.  Since that workqueue isn't freezable, the
    polling continues even in the middle of a system sleep transition.
    Obviously, polling a suspended drive for media changes and such isn't
    a good thing to do; in the case of USB mass-storage devices it can
    lead to real problems requiring device resets and even re-enumeration.
    The patch fixes things by creating a new system-wide, non-reentrant,
    freezable workqueue and using it for disk-events polling.
    Signed-off-by: Alan Stern <>
    Acked-by: Tejun Heo <>
    Acked-by: Rafael J. Wysocki <>
    Signed-off-by: Jens Axboe <>
    Signed-off-by: Greg Kroah-Hartman <>
    Alan Stern committed with gregkh Mar 2, 2012
  9. @sgruszka @gregkh

    block: fix __blkdev_get and add_disk race condition

    commit 9f53d2f upstream.
    The following situation might occur:
    __blkdev_get:			add_disk:
    	disk->ev == NULL
    	disk->ev != NULL
    Then we unblock events, when they are suppose to be blocked. This can
    trigger events related block/genhd.c warnings, but also can crash in
    sd_check_events() or other places.
    I'm able to reproduce crashes with the following scripts (with
    connected usb dongle as sdb disk).
    function stop_me()
    	for i in `jobs -p` ; do kill $i 2> /dev/null ; done
    trap stop_me SIGHUP SIGINT SIGTERM
    for ((i = 0; i < 10; i++)) ; do
    	while true; do fdisk -l $DEV  2>&1 > /dev/null ; done &
    while true ; do
    echo 1 > $ENABLE
    sleep 1
    echo 0 > $ENABLE
    I use the script to verify patch fixing oops in sd_revalidate_disk
    Without Jun'ichi Nomura patch titled "Fix NULL pointer dereference in
    sd_revalidate_disk" or this one, script easily crash kernel within
    a few seconds. With both patches applied I do not observe crash.
    Unfortunately after some time (dozen of minutes), script will hung in:
    [ 1563.906432]  [<c08354f5>] schedule_timeout_uninterruptible+0x15/0x20
    [ 1563.906437]  [<c04532d5>] msleep+0x15/0x20
    [ 1563.906443]  [<c05d60b2>] blk_drain_queue+0x32/0xd0
    [ 1563.906447]  [<c05d6e00>] blk_cleanup_queue+0xd0/0x170
    [ 1563.906454]  [<c06d278f>] scsi_free_queue+0x3f/0x60
    [ 1563.906459]  [<c06d7e6e>] __scsi_remove_device+0x6e/0xb0
    [ 1563.906463]  [<c06d4aff>] scsi_forget_host+0x4f/0x60
    [ 1563.906468]  [<c06cd84a>] scsi_remove_host+0x5a/0xf0
    [ 1563.906482]  [<f7f030fb>] quiesce_and_remove_host+0x5b/0xa0 [usb_storage]
    [ 1563.906490]  [<f7f03203>] usb_stor_disconnect+0x13/0x20 [usb_storage]
    Anyway I think this patch is some step forward.
    As drawback, I do not teardown on sysfs file create error, because I do
    not know how to nullify disk->ev (since it can be used). However add_disk
    error handling practically does not exist too, and things will work
    without this sysfs file, except events will not be exported to user
    Signed-off-by: Stanislaw Gruszka <>
    Acked-by: Tejun Heo <>
    Signed-off-by: Jens Axboe <>
    Signed-off-by: Greg Kroah-Hartman <>
    sgruszka committed with gregkh Mar 2, 2012
  10. @theif @gregkh

    block, sx8: fix pointer math issue getting fw version

    commit ea5f4db upstream.
    "mem" is type u8.  We need parenthesis here or it screws up the pointer
    math probably leading to an oops.
    Signed-off-by: Dan Carpenter <>
    Acked-by: Jeff Garzik <>
    Signed-off-by: Jens Axboe <>
    Signed-off-by: Greg Kroah-Hartman <>
    theif committed with gregkh Mar 3, 2012
  11. @gregkh

    block: Fix NULL pointer dereference in sd_revalidate_disk

    commit fe316bf upstream.
    Since 2.6.39 (1196f8b), when a driver returns -ENOMEDIUM for open(),
    __blkdev_get() calls rescan_partitions() to remove
    in-kernel partition structures and raise KOBJ_CHANGE uevent.
    However it ends up calling driver's revalidate_disk without open
    and could cause oops.
    In the case of SCSI:
      process A                  process B
            returns -ENOMEDIUM
                                   <scsi_device torn down>
    Oopses are reported here:
    This patch separates the partition invalidation from rescan_partitions()
    and use it for -ENOMEDIUM case.
    Reported-by: Huajun Li <>
    Signed-off-by: Jun'ichi Nomura <>
    Acked-by: Tejun Heo <>
    Signed-off-by: Jens Axboe <>
    Signed-off-by: Greg Kroah-Hartman <>
    Jun'ichi Nomura committed with gregkh Mar 2, 2012
  12. @AxelLin @gregkh

    regulator: Fix setting selector in tps6524x set_voltage function

    commit f03570c upstream.
    Don't assign the voltage to selector.
    Signed-off-by: Axel Lin <>
    Signed-off-by: Mark Brown <>
    Signed-off-by: Greg Kroah-Hartman <>
    AxelLin committed with gregkh Mar 8, 2012
  13. @gregkh

    compat: Re-add missing asm/compat.h include to fix compile breakage o…

    …n s390
    For kernels <= 3.0 the backport of 048cd4e
    "compat: fix compile breakage on s390" will break compilation...
    Re-add a single #include <asm/compat.h> in order to fix this.
    This patch is _not_ necessary for upstream, only for stable kernels
    which include the "build fix" mentioned above.
    Reported-by: Jiri Slaby <>
    Signed-off-by: Heiko Carstens <>
    Heiko Carstens committed with gregkh Mar 5, 2012
  14. @gregkh

    usb: asix: Patch for Sitecom LN-031

    commit 4e50391 upstream.
    This patch adds support for the Sitecom LN-031 USB adapter with a AX88178 chip.
    Added USB id to find correct driver for AX88178 1000 Ethernet adapter.
    Signed-off-by: Joerg Neikes <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Joerg Neikes committed with gregkh Mar 8, 2012
  15. @gregkh

    atl1c: dont use highprio tx queue

    [ Upstream commit 11aad99 ]
    This driver attempts to use two TX rings but lacks proper support :
    1) IRQ handler only takes care of TX completion on first TX ring
    2) the stop/start logic uses the legacy functions (for non multiqueue
    This means all packets witk skb mark set to 1 are sent through high
    queue but are never cleaned and queue eventualy fills and block the
    device, triggering the infamous "NETDEV WATCHDOG" message.
    Lets use a single TX ring to fix the problem, this driver is not a real
    multiqueue one yet.
    Minimal fix for stable kernels.
    Reported-by: Thomas Meyer <>
    Tested-by: Thomas Meyer <>
    Signed-off-by: Eric Dumazet <>
    Cc: Jay Cliburn <>
    Cc: Chris Snook <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Eric Dumazet committed with gregkh Feb 15, 2012
  16. @liwei @gregkh

    IPv6: Fix not join all-router mcast group when forwarding set.

    [ Upstream commit d6ddef9 ]
    When forwarding was set and a new net device is register,
    we need add this device to the all-router mcast group.
    Signed-off-by: Li Wei <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    liwei committed with gregkh Mar 5, 2012
  17. @gregkh

    tcp: fix tcp_shift_skb_data() to not shift SACKed data below snd_una

    [ Upstream commit 4648dc9 ]
    This commit fixes tcp_shift_skb_data() so that it does not shift
    SACKed data below snd_una.
    This fixes an issue whose symptoms exactly match reports showing
    tp->sacked_out going negative since 3.3.0-rc4 (see "WARNING: at
    net/ipv4/tcp_input.c:3418" thread on netdev).
    Since 2008 (832d11c)
    tcp_shift_skb_data() had been shifting SACKed ranges that were below
    snd_una. It checked that the *end* of the skb it was about to shift
    from was above snd_una, but did not check that the end of the actual
    shifted range was above snd_una; this commit adds that check.
    Shifting SACKed ranges below snd_una is problematic because for such
    ranges tcp_sacktag_one() short-circuits: it does not declare anything
    as SACKed and does not increase sacked_out.
    Before the fixes in commits cc9a672
    and daef52b, shifting SACKed ranges
    below snd_una happened to work because tcp_shifted_skb() was always
    (incorrectly) passing in to tcp_sacktag_one() an skb whose end_seq
    tcp_shift_skb_data() had already guaranteed was beyond snd_una. Hence
    tcp_sacktag_one() never short-circuited and always increased
    tp->sacked_out in this case.
    After those two fixes, my testing has verified that shifting SACKed
    ranges below snd_una could cause tp->sacked_out to go negative with
    the following sequence of events:
    (1) tcp_shift_skb_data() sees an skb whose end_seq is beyond snd_una,
        then shifts a prefix of that skb that is below snd_una
    (2) tcp_shifted_skb() increments the packet count of the
        already-SACKed prev sk_buff
    (3) tcp_sacktag_one() sees the end of the new SACKed range is below
        snd_una, so it short-circuits and doesn't increase tp->sacked_out
    (5) tcp_clean_rtx_queue() sees the SACKed skb has been ACKed,
        decrements tp->sacked_out by this "inflated" pcount that was
        missing a matching increase in tp->sacked_out, and hence
        tp->sacked_out underflows to a u32 like 0xFFFFFFFF, which casted
        to s32 is negative.
    (6) this leads to the warnings seen in the recent "WARNING: at
        net/ipv4/tcp_input.c:3418" thread on the netdev list; e.g.:
        tcp_input.c:3418  WARN_ON((int)tp->sacked_out < 0);
    More generally, I think this bug can be tickled in some cases where
    two or more ACKs from the receiver are lost and then a DSACK arrives
    that is immediately above an existing SACKed skb in the write queue.
    This fix changes tcp_shift_skb_data() to abort this sequence at step
    (1) in the scenario above by noticing that the bytes are below snd_una
    and not shifting them.
    Signed-off-by: Neal Cardwell <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Neal Cardwell committed with gregkh Mar 5, 2012
  18. @gregkh

    bridge: check return value of ipv6_dev_get_saddr()

    [ Upstream commit d1d81d4 ]
    otherwise source IPv6 address of ICMPV6_MGM_QUERY packet
    might be random junk if IPv6 is disabled on interface or
    link-local address is not yet ready (DAD).
    Signed-off-by: Ulrich Weber <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Ulrich Weber committed with gregkh Mar 5, 2012
  19. @gregkh

    tcp: don't fragment SACKed skbs in tcp_mark_head_lost()

    [ Upstream commit c0638c2 ]
    In tcp_mark_head_lost() we should not attempt to fragment a SACKed skb
    to mark the first portion as lost. This is for two primary reasons:
    (1) tcp_shifted_skb() coalesces adjacent regions of SACKed skbs. When
    doing this, it preserves the sum of their packet counts in order to
    reflect the real-world dynamics on the wire. But given that skbs can
    have remainders that do not align to MSS boundaries, this packet count
    preservation means that for SACKed skbs there is not necessarily a
    direct linear relationship between tcp_skb_pcount(skb) and
    skb->len. Thus tcp_mark_head_lost()'s previous attempts to fragment
    off and mark as lost a prefix of length (packets - oldcnt)*mss from
    SACKed skbs were leading to occasional failures of the WARN_ON(len >
    skb->len) in tcp_fragment() (which used to be a BUG_ON(); see the
    recent "crash in tcp_fragment" thread on netdev).
    (2) there is no real point in fragmenting off part of a SACKed skb and
    calling tcp_skb_mark_lost() on it, since tcp_skb_mark_lost() is a NOP
    for SACKed skbs.
    Signed-off-by: Neal Cardwell <>
    Acked-by: Ilpo Järvinen <>
    Acked-by: Yuchung Cheng <>
    Acked-by: Nandita Dukkipati <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Neal Cardwell committed with gregkh Mar 2, 2012
  20. @gregkh

    vmxnet3: Fix transport header size

    [ Upstream commit efead87 ]
    Fix transport header size
    Fix the transpoert header size for UDP packets.
    Signed-off-by: Shreyas N Bhatewara <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Shreyas Bhatewara committed with gregkh Feb 28, 2012
  21. @gregkh

    tcp: fix false reordering signal in tcp_shifted_skb

    [ Upstream commit 4c90d3b ]
    When tcp_shifted_skb() shifts bytes from the skb that is currently
    pointed to by 'highest_sack' then the increment of
    TCP_SKB_CB(skb)->seq implicitly advances tcp_highest_sack_seq(). This
    implicit advancement, combined with the recent fix to pass the correct
    SACKed range into tcp_sacktag_one(), caused tcp_sacktag_one() to think
    that the newly SACKed range was before the tcp_highest_sack_seq(),
    leading to a call to tcp_update_reordering() with a degree of
    reordering matching the size of the newly SACKed range (typically just
    1 packet, which is a NOP, but potentially larger).
    This commit fixes this by simply calling tcp_sacktag_one() before the
    TCP_SKB_CB(skb)->seq advancement that can advance our notion of the
    highest SACKed sequence.
    Correspondingly, we can simplify the code a little now that
    tcp_shifted_skb() should update the lost_cnt_hint in all cases where
    skb == tp->lost_skb_hint.
    Signed-off-by: Neal Cardwell <>
    Acked-by: Yuchung Cheng <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Neal Cardwell committed with gregkh Feb 26, 2012
  22. @gregkh

    ppp: fix 'ppp_mp_reconstruct bad seq' errors

    [ Upstream commit 8a49ad6 ]
    This patch fixes a (mostly cosmetic) bug introduced by the patch
    'ppp: Use SKB queue abstraction interfaces in fragment processing'
    found here:
    The above patch rewrote and moved the code responsible for cleaning
    up discarded fragments but the new code does not catch every case
    where this is necessary.  This results in some discarded fragments
    remaining in the queue, and triggering a 'bad seq' error on the
    subsequent call to ppp_mp_reconstruct.  Fragments are discarded
    whenever other fragments of the same frame have been lost.
    This can generate a lot of unwanted and misleading log messages.
    This patch also adds additional detail to the debug logging to
    make it clearer which fragments were lost and which other fragments
    were discarded as a result of losses. (Run pppd with 'kdebug 1'
    option to enable debug logging.)
    Signed-off-by: Ben McKeegan <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Ben McKeegan committed with gregkh Feb 24, 2012
  23. @gregkh

    ipsec: be careful of non existing mac headers

    [ Upstream commit 0360689 ]
    Niccolo Belli reported ipsec crashes in case we handle a frame without
    mac header (atm in his case)
    Before copying mac header, better make sure it is present.
    Bugzilla reference:
    Reported-by: Niccolò Belli <>
    Tested-by: Niccolò Belli <>
    Signed-off-by: Eric Dumazet <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Eric Dumazet committed with gregkh Feb 23, 2012
  24. @AltraMayor @gregkh

    neighbour: Fixed race condition at tbl->nht

    [ Upstream commit 84338a6 ]
    When the fixed race condition happens:
    1. While function neigh_periodic_work scans the neighbor hash table
    pointed by field tbl->nht, it unlocks and locks tbl->lock between
    buckets in order to call cond_resched.
    2. Assume that function neigh_periodic_work calls cond_resched, that is,
    the lock tbl->lock is available, and function neigh_hash_grow runs.
    3. Once function neigh_hash_grow finishes, and RCU calls
    neigh_hash_free_rcu, the original struct neigh_hash_table that function
    neigh_periodic_work was using doesn't exist anymore.
    4. Once back at neigh_periodic_work, whenever the old struct
    neigh_hash_table is accessed, things can go badly.
    Signed-off-by: Michel Machado <>
    CC: "David S. Miller" <>
    CC: Eric Dumazet <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    AltraMayor committed with gregkh Feb 21, 2012
  25. @ikepanhc @gregkh

    acer-wmi: No wifi rfkill on Lenovo machines

    commit 461e743 upstream.
    We have several reports which says acer-wmi is loaded on ideapads
    and register rfkill for wifi which can not be unblocked.
    Since ideapad-laptop also register rfkill for wifi and it works
    reliably, it will be fine acer-wmi is not going to register rfkill
    for wifi once VPC2004 is found.
    Also put IBM0068/LEN0068 in the list. Though thinkpad_acpi has no
    wifi rfkill capability, there are reports which says acer-wmi also
    block wireless on Thinkpad E520/E420.
    Signed-off-by: Ike Panhc <>
    Signed-off-by: Matthew Garrett <>
    Cc: Jonathan Nieder <>
    Signed-off-by: Greg Kroah-Hartman <>
    ikepanhc committed with gregkh Feb 3, 2012
  26. @gregkh

    acer-wmi: check wireless capability flag before register rfkill

    commit 1709ada upstream.
    There will be better to check the wireless capability flag
    (ACER_CAP_WIRELESS) before register wireless rfkill because maybe
    the machine doesn't have wifi module or the module removed by user.
    Tested on Acer Travelmate 8572
    Tested on Acer Aspire 4739Z
    Tested-by: AceLan Kao <>
    Cc: Carlos Corbacho <>
    Cc: Matthew Garrett <>
    Cc: Dmitry Torokhov <>
    Cc: Corentin Chary <>
    Cc: Thomas Renninger <>
    Signed-off-by: Lee, Chun-Yi <>
    Signed-off-by: Matthew Garrett <>
    Signed-off-by: Greg Kroah-Hartman <>
    Lee, Chun-Yi committed with gregkh Aug 18, 2011
Something went wrong with that request. Please try again.