20 Mar, 2012

38 commits

  • commit 8ee161ce5e0cfc689eb677f227a6248191165fac 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
     
  • commit 9bbad7da76b3dd578fb55c862624366a8c9ccd22 upstream.

    Fix indexed register offset definitions that use decimal (wrong) instead
    of hexadecimal (correct) notation for indexing multipliers.

    Incorrect definitions do not affect Tsi721 driver in its current default
    configuration because it uses only IDB queue 0. Loss of inbound
    doorbell functionality should be observed if queue other than 0 is used.

    Signed-off-by: Alexandre Bounine
    Cc: Matt Porter
    Cc: Chul Kim
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Alexandre Bounine
     
  • commit aacb6b0052692c72fe0cb94c6b547202def6ef46 upstream.

    Properly set the source of temp2 for the W83627UHG. Also fix a
    comment right before that, and document the W83627UHG as reporting up
    to 3 temperatures.

    Signed-off-by: Jean Delvare
    Cc: Guenter Roeck
    Signed-off-by: Guenter Roeck
    Signed-off-by: Greg Kroah-Hartman

    Jean Delvare
     
  • commit 32260d94408c553dca4ce54104edf79941a27536 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

    Guenter Roeck
     
  • commit 33fa9b620409edfc71aa6cf01a51f990fbe46ab8 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

    Guenter Roeck
     
  • commit e0adb9902fb338a9fe634c3c2a3e474075c733ba 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

    David S. Miller
     
  • commit 62d3c5439c534b0e6c653fc63e6d8c67be3a57b1 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
     
  • commit 9f53d2fe815b4011ff930a7b6db98385d45faa68 upstream.

    The following situation might occur:

    __blkdev_get: add_disk:

    register_disk()
    get_gendisk()

    disk_block_events()
    disk->ev == NULL

    disk_add_events()

    __disk_unblock_events()
    disk->ev != NULL
    --ev->block

    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).

    DEV=/dev/sdb
    ENABLE=/sys/bus/usb/devices/1-2/bConfigurationValue

    function stop_me()
    {
    for i in `jobs -p` ; do kill $i 2> /dev/null ; done
    exit
    }

    trap stop_me SIGHUP SIGINT SIGTERM

    for ((i = 0; i < 10; i++)) ; do
    while true; do fdisk -l $DEV 2>&1 > /dev/null ; done &
    done

    while true ; do
    echo 1 > $ENABLE
    sleep 1
    echo 0 > $ENABLE
    done

    I use the script to verify patch fixing oops in sd_revalidate_disk
    http://marc.info/?l=linux-scsi&m=132935572512352&w=2
    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] [] schedule_timeout_uninterruptible+0x15/0x20
    [ 1563.906437] [] msleep+0x15/0x20
    [ 1563.906443] [] blk_drain_queue+0x32/0xd0
    [ 1563.906447] [] blk_cleanup_queue+0xd0/0x170
    [ 1563.906454] [] scsi_free_queue+0x3f/0x60
    [ 1563.906459] [] __scsi_remove_device+0x6e/0xb0
    [ 1563.906463] [] scsi_forget_host+0x4f/0x60
    [ 1563.906468] [] scsi_remove_host+0x5a/0xf0
    [ 1563.906482] [] quiesce_and_remove_host+0x5b/0xa0 [usb_storage]
    [ 1563.906490] [] 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
    space.

    Signed-off-by: Stanislaw Gruszka
    Acked-by: Tejun Heo
    Signed-off-by: Jens Axboe
    Signed-off-by: Greg Kroah-Hartman

    Stanislaw Gruszka
     
  • commit ea5f4db8ece896c2ab9eafa0924148a2596c52e4 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

    Dan Carpenter
     
  • commit fe316bf2d5847bc5dd975668671a7b1067603bc7 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
    ----------------------------------------------
    sys_open
    __blkdev_get
    sd_open
    returns -ENOMEDIUM
    scsi_remove_device

    rescan_partitions
    sd_revalidate_disk

    Oopses are reported here:
    http://marc.info/?l=linux-scsi&m=132388619710052

    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
     
  • commit f03570cf1709397ebe656608266b44ec772960c2 upstream.

    Don't assign the voltage to selector.

    Signed-off-by: Axel Lin
    Signed-off-by: Mark Brown
    Signed-off-by: Greg Kroah-Hartman

    Axel Lin
     
  • commit 4e50391968849860dff1aacde358b4eb14aa5127 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
     
  • [ Upstream commit d6ddef9e641d1229d4ec841dc75ae703171c3e92 ]

    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

    Li Wei
     
  • [ Upstream commit 4648dc97af9d496218a05353b0e442b3dfa6aaab ]

    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 (832d11c5cd076abc0aa1eaf7be96c81d1a59ce41)
    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 cc9a672ee522d4805495b98680f4a3db5d0a0af9
    and daef52bab1fd26e24e8e9578f8fb33ba1d0cb412, 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
     
  • [ Upstream commit d1d81d4c3dd886d5fa25a2c4fa1e39cb89613712 ]

    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
     
  • [ Upstream commit c0638c247f559e1a16ee79e54df14bca2cb679ea ]

    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
     
  • [ Upstream commit 9c5028e9da1255dd2b99762d8627b88b29f68cce ]

    Noticed with the 8168d (-vb-gr, aka RTL_GIGA_MAC_VER_26).

    ConfigX registers should only be written while the Config9346 lock
    is held.

    Signed-off-by: Francois Romieu
    Reported-by: Nick Bowler
    Cc: Hayes Wang
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    françois romieu
     
  • [ Upstream commit 3f2010b2ad3d66d5291497c9b274315e7b807ecd ]

    As part of the big network driver reorg, each vendor directory defaults to
    yes, so that older config's can migrate correctly. Looks like this one
    got missed.

    Signed-off-by: Stephen Hemminger
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    stephen hemminger
     
  • [ Upstream commit efead8710aad9e384730ecf25eae0287878840d7 ]

    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
     
  • [ Upstream commit 4c90d3b30334833450ccbb02f452d4972a3c3c3f ]

    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
     
  • [ Upstream commit ff3bc1e7527504a93710535611b2f812f3bb89bf ]

    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 bc8acf2c8c3e43fcc192762a9f964b3e9a17748b ('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
    efx_rx_packet_gro().

    Signed-off-by: Ben Hutchings
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Ben Hutchings
     
  • [ Upstream commit 8a49ad6e89feb5015e77ce6efeb2678947117e20 ]

    This patch fixes a (mostly cosmetic) bug introduced by the patch
    'ppp: Use SKB queue abstraction interfaces in fragment processing'
    found here: http://www.spinics.net/lists/netdev/msg153312.html

    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
     
  • [ Upstream commit 03606895cd98c0a628b17324fd7b5ff15db7e3cd ]

    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: https://bugzilla.kernel.org/show_bug.cgi?id=42809

    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
     
  • [ Upstream commit 84338a6c9dbb6ff3de4749864020f8f25d86fc81 ]

    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

    Michel Machado
     
  • [ Upstream commit 11aad99af6ef629ff3b05d1c9f0936589b204316 ]

    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
    drivers)

    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
     
  • commit 461e74377cfcfc2c0d6bbdfa8fc5fbc21b052c2a 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

    Ike Panhc
     
  • commit 097b180ca09b581ef0dc24fbcfc1b227de3875df upstream.

    complete_walk() already puts nd->path, no need to do it again at cleanup time.

    This would result in Oopses if triggered, apparently the codepath is not too
    well exercised.

    Signed-off-by: Miklos Szeredi
    Signed-off-by: Al Viro
    Signed-off-by: Greg Kroah-Hartman

    Miklos Szeredi
     
  • commit 7f6c7e62fcc123e6bd9206da99a2163fe3facc31 upstream.

    complete_walk() returns either ECHILD or ESTALE. do_last() turns this into
    ECHILD unconditionally. If not in RCU mode, this error will reach userspace
    which is complete nonsense.

    Signed-off-by: Miklos Szeredi
    Signed-off-by: Al Viro
    Signed-off-by: Greg Kroah-Hartman

    Miklos Szeredi
     
  • commit d5751469f210d2149cc2159ffff66cbeef6da3f2 upstream.

    Reorganize the code to make the memory already allocated before
    spinlock'ed loop.

    Reviewed-by: Jeff Layton
    Signed-off-by: Pavel Shilovsky
    Signed-off-by: Steve French
    Signed-off-by: Greg Kroah-Hartman

    Pavel Shilovsky
     
  • commit 87e24f4b67e68d9fd8df16e0bf9c66d1ad2a2533 upstream.

    Verified using the below proglet.. before:

    [root@westmere ~]# perf stat -e node-stores -e node-store-misses ./numa 0
    remote write

    Performance counter stats for './numa 0':

    2,101,554 node-stores
    2,096,931 node-store-misses

    5.021546079 seconds time elapsed

    [root@westmere ~]# perf stat -e node-stores -e node-store-misses ./numa 1
    local write

    Performance counter stats for './numa 1':

    501,137 node-stores
    199 node-store-misses

    5.124451068 seconds time elapsed

    After:

    [root@westmere ~]# perf stat -e node-stores -e node-store-misses ./numa 0
    remote write

    Performance counter stats for './numa 0':

    2,107,516 node-stores
    2,097,187 node-store-misses

    5.012755149 seconds time elapsed

    [root@westmere ~]# perf stat -e node-stores -e node-store-misses ./numa 1
    local write

    Performance counter stats for './numa 1':

    2,063,355 node-stores
    165 node-store-misses

    5.082091494 seconds time elapsed

    #define _GNU_SOURCE

    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include

    #define SIZE (32*1024*1024)

    volatile int done;

    void sig_done(int sig)
    {
    done = 1;
    }

    int main(int argc, char **argv)
    {
    cpu_set_t *mask, *mask2;
    size_t size;
    int i, err, t;
    int nrcpus = 1024;
    char *mem;
    unsigned long nodemask = 0x01; /* node 0 */
    DIR *node;
    struct dirent *de;
    int read = 0;
    int local = 0;

    if (argc < 2) {
    printf("usage: %s [0-3]\n", argv[0]);
    printf(" bit0 - local/remote\n");
    printf(" bit1 - read/write\n");
    exit(0);
    }

    switch (atoi(argv[1])) {
    case 0:
    printf("remote write\n");
    break;
    case 1:
    printf("local write\n");
    local = 1;
    break;
    case 2:
    printf("remote read\n");
    read = 1;
    break;
    case 3:
    printf("local read\n");
    local = 1;
    read = 1;
    break;
    }

    mask = CPU_ALLOC(nrcpus);
    size = CPU_ALLOC_SIZE(nrcpus);
    CPU_ZERO_S(size, mask);

    node = opendir("/sys/devices/system/node/node0/");
    if (!node)
    perror("opendir");
    while ((de = readdir(node))) {
    int cpu;

    if (sscanf(de->d_name, "cpu%d", &cpu) == 1)
    CPU_SET_S(cpu, size, mask);
    }
    closedir(node);

    mask2 = CPU_ALLOC(nrcpus);
    CPU_ZERO_S(size, mask2);
    for (i = 0; i < size; i++)
    CPU_SET_S(i, size, mask2);
    CPU_XOR_S(size, mask2, mask2, mask); // invert

    if (!local)
    mask = mask2;

    err = sched_setaffinity(0, size, mask);
    if (err)
    perror("sched_setaffinity");

    mem = mmap(0, SIZE, PROT_READ|PROT_WRITE,
    MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
    err = mbind(mem, SIZE, MPOL_BIND, &nodemask, 8*sizeof(nodemask), MPOL_MF_MOVE);
    if (err)
    perror("mbind");

    signal(SIGALRM, sig_done);
    alarm(5);

    if (!read) {
    while (!done) {
    for (i = 0; i < SIZE; i++)
    mem[i] = 0x01;
    }
    } else {
    while (!done) {
    for (i = 0; i < SIZE; i++)
    t += *(volatile char *)(mem + i);
    }
    }

    return 0;
    }

    Signed-off-by: Peter Zijlstra
    Cc: Stephane Eranian
    Link: http://lkml.kernel.org/n/tip-tq73sxus35xmqpojf7ootxgs@git.kernel.org
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Peter Zijlstra
     
  • commit 3780d038fdf4b5ef26ead10b0604ab1f46dd9510 upstream.

    Is possible that we stop queue and then do not wake up it again,
    especially when packets are transmitted fast. That can be easily
    reproduced with modified tx queue entry_num to some small value e.g. 16.

    If mac80211 already hold local->queue_stop_reason_lock, then we can wait
    on that lock in both rt2x00queue_pause_queue() and
    rt2x00queue_unpause_queue(). After drooping ->queue_stop_reason_lock
    is possible that __ieee80211_wake_queue() will be performed before
    __ieee80211_stop_queue(), hence we stop queue and newer wake up it
    again.

    Another race condition is possible when between rt2x00queue_threshold()
    check and rt2x00queue_pause_queue() we will process all pending tx
    buffers on different cpu. This might happen if for example interrupt
    will be triggered on cpu performing rt2x00mac_tx().

    To prevent race conditions serialize pause/unpause by queue->tx_lock.

    Signed-off-by: Stanislaw Gruszka
    Acked-by: Gertjan van Wingerde
    Signed-off-by: John W. Linville
    Signed-off-by: Greg Kroah-Hartman

    Stanislaw Gruszka
     
  • commit bd0f2e6da7ea9e225cb2dbd3229e25584b0e9538 upstream.

    The HS/VS interrupt handler needs to access the pipeline object. It
    erronously tries to get it from the CCDC output video node, which isn't
    necessarily included in the pipeline. This leads to a NULL pointer
    dereference.

    Fix the bug by getting the pipeline object from the CCDC subdev entity.

    Reported-by: Gary Thomas
    Signed-off-by: Laurent Pinchart
    Acked-by: Sakari Ailus
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Greg Kroah-Hartman

    Laurent Pinchart
     
  • commit 4949be16822e92a18ea0cc1616319926628092ee upstream.

    Right now we won't touch ASPM state if ASPM is disabled, except in the case
    where we find a device that appears to be too old to reliably support ASPM.
    Right now we'll clear it in that case, which is almost certainly the wrong
    thing to do. The easiest way around this is just to disable the blacklisting
    when ASPM is disabled.

    Signed-off-by: Matthew Garrett
    Signed-off-by: Jesse Barnes
    Signed-off-by: Greg Kroah-Hartman

    Matthew Garrett
     
  • commit a7f4255f906f60f72e00aad2fb000939449ff32e upstream.

    Commit f0fbf0abc093 ("x86: integrate delay functions") converted
    delay_tsc() into a random delay generator for 64 bit. The reason is
    that it merged the mostly identical versions of delay_32.c and
    delay_64.c. Though the subtle difference of the result was:

    static void delay_tsc(unsigned long loops)
    {
    - unsigned bclock, now;
    + unsigned long bclock, now;

    Now the function uses rdtscl() which returns the lower 32bit of the
    TSC. On 32bit that's not problematic as unsigned long is 32bit. On 64
    bit this fails when the lower 32bit are close to wrap around when
    bclock is read, because the following check

    if ((now - bclock) >= loops)
    break;

    evaluated to true on 64bit for e.g. bclock = 0xffffffff and now = 0
    because the unsigned long (now - bclock) of these values results in
    0xffffffff00000001 which is definitely larger than the loops
    value. That explains Tvortkos observation:

    "Because I am seeing udelay(500) (_occasionally_) being short, and
    that by delaying for some duration between 0us (yep) and 491us."

    Make those variables explicitely u32 again, so this works for both 32
    and 64 bit.

    Reported-by: Tvrtko Ursulin
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     
  • commit c7b285550544c22bc005ec20978472c9ac7138c6 upstream.

    Current code has put_ioctx() called asynchronously from aio_fput_routine();
    that's done *after* we have killed the request that used to pin ioctx,
    so there's nothing to stop io_destroy() waiting in wait_for_all_aios()
    from progressing. As the result, we can end up with async call of
    put_ioctx() being the last one and possibly happening during exit_mmap()
    or elf_core_dump(), neither of which expects stray munmap() being done
    to them...

    We do need to prevent _freeing_ ioctx until aio_fput_routine() is done
    with that, but that's all we care about - neither io_destroy() nor
    exit_aio() will progress past wait_for_all_aios() until aio_fput_routine()
    does really_put_req(), so the ioctx teardown won't be done until then
    and we don't care about the contents of ioctx past that point.

    Since actual freeing of these suckers is RCU-delayed, we don't need to
    bump ioctx refcount when request goes into list for async removal.
    All we need is rcu_read_lock held just over the ->ctx_lock-protected
    area in aio_fput_routine().

    Signed-off-by: Al Viro
    Reviewed-by: Jeff Moyer
    Acked-by: Benjamin LaHaise
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Al Viro
     
  • commit 86b62a2cb4fc09037bbce2959d2992962396fd7f upstream.

    Have ioctx_alloc() return an extra reference, so that caller would drop it
    on success and not bother with re-grabbing it on failure exit. The current
    code is obviously broken - io_destroy() from another thread that managed
    to guess the address io_setup() would've returned would free ioctx right
    under us; gets especially interesting if aio_context_t * we pass to
    io_setup() points to PROT_READ mapping, so put_user() fails and we end
    up doing io_destroy() on kioctx another thread has just got freed...

    Signed-off-by: Al Viro
    Acked-by: Benjamin LaHaise
    Reviewed-by: Jeff Moyer
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Al Viro
     
  • commit 526af6eb4dc71302f59806e2ccac7793963a7fe0 upstream.

    The coef setup in alc269_fill_coef() was designed only for ALC269VB
    model, and this has some bad effects for other ALC269 variants, such
    as turning off the external mic input. Apply it only to ALC269VB.

    Signed-off-by: Kailang Yang
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Kailang Yang
     
  • commit b2ccf065f7b23147ed135a41b01d05a332ca6b7e upstream.

    The neo1973 driver had wrong codec name which prevented the "sound card"
    from appearing.

    Signed-off-by: Denis 'GNUtoo' Carikli
    Signed-off-by: Mark Brown
    Signed-off-by: Greg Kroah-Hartman

    Denis 'GNUtoo' Carikli
     

14 Mar, 2012

2 commits