Linux 3.0.92

commit 497c6eb673d94487cfde35c7077981733fe862fb
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Aug 20 08:21:23 2013 -0700

    Linux 3.0.92

commit c4e462a085dd8279af22493ad0858d73e0bcafe1
Author: Andreas Schwab <schwab@linux-m68k.org>
Date:   Fri Aug 9 15:14:08 2013 +0200

    m68k: Truncate base in do_div()

    commit ea077b1b96e073eac5c3c5590529e964767fc5f7 upstream.

    Explicitly truncate the second operand of do_div() to 32 bits to guard
    against bogus code calling it with a 64-bit divisor.

    [Thorsten]

    After upgrading from 3.2 to 3.10, mounting a btrfs volume fails with:

    btrfs: setting nodatacow, compression disabled
    btrfs: enabling auto recovery
    btrfs: disk space caching is enabled
     *** ZERO DIVIDE ***   FORMAT=2
    Current process id is 722
    BAD KERNEL TRAP: 00000000
    Modules linked in: evdev mac_hid ext4 crc16 jbd2 mbcache btrfs xor lzo_compress zlib_deflate raid6_pq crc32c libcrc32c
    PC: [<319535b2>] __btrfs_map_block+0x11c/0x119a [btrfs]
    SR: 2000  SP: 30c1fab4  a2: 30f0faf0
    d0: 00000000    d1: 00001000    d2: 00000000    d3: 00000000
    d4: 00010000    d5: 00000000    a0: 3085c72c    a1: 3085c72c
    Process mount (pid: 722, task=30f0faf0)
    Frame format=2 instr addr=319535ae
    Stack from 30c1faec:
            00000000 00000020 00000000 00001000 00000000 01401000 30253928 300ffc00
            00a843ac 3026f640 00000000 00010000 0009e250 00d106c0 00011220 00000000
            00001000 301c6830 0009e32a 000000ff 00000009 3085c72c 00000000 00000000
            30c1fd14 00000000 00000020 00000000 30c1fd14 0009e26c 00000020 00000003
            00000000 0009dd8a 300b0b6c 30253928 00a843ac 00001000 00000000 00000000
            0000a008 3194e76a 30253928 00a843ac 00001000 00000000 00000000 00000002
    Call Trace: [<00001000>] kernel_pg_dir+0x0/0x1000

        [...]

    Code: 222e ff74 2a2e ff5c 2c2e ff60 4c45 1402 <2d40> ff64 2d41 ff68 2205 4c2e 1800 ff68 4c04 0800 2041 d1c0 2206 4c2e 1400 ff68

    [Geert]

    As diagnosed by Andreas, fs/btrfs/volumes.c:__btrfs_map_block()
    calls

        do_div(stripe_nr, stripe_len);

    with stripe_len u64, while do_div() assumes the divisor is a 32-bit number.

    Due to the lack of truncation in the m68k-specific implementation of
    do_div(), the division is performed using the upper 32-bit word of
    stripe_len, which is zero.

    This was introduced by commit 53b381b3abeb86f12787a6c40fee9b2f71edc23b
    ("Btrfs: RAID5 and RAID6"), which changed the divisor from
    map->stripe_len (struct map_lookup.stripe_len is int) to a 64-bit temporary.

    Reported-by: Thorsten Glaser <tg@debian.org>
    Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
    Tested-by: Thorsten Glaser <tg@debian.org>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a9a85d5fb90db72d8e0618a0fafa2069be86198
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Apr 27 13:25:38 2013 -0700

    vm: add no-mmu vm_iomap_memory() stub

    commit 3c0b9de6d37a481673e81001c57ca0e410c72346 upstream.

    I think we could just move the full vm_iomap_memory() function into
    util.h or similar, but I didn't get any reply from anybody actually
    using nommu even to this trivial patch, so I'm not going to touch it any
    more than required.

    Here's the fairly minimal stub to make the nommu case at least
    potentially work.  It doesn't seem like anybody cares, though.

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e69b54fa8b48e3cdc1a78f77beab3af763a33a1
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Tue Sep 6 07:45:46 2011 +0100

    ARM: 7080/1: l2x0: make sure I&D are not locked down on init

    commit bac7e6ecf60933b68af910eb4c83a775a8b20b19 upstream.

    Fighting unfixed U-Boots and other beasts that may the cache in
    a locked-down state when starting the kernel, we make sure to
    disable all cache lock-down when initializing the l2x0 so we
    are in a known state.

    Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
    Reported-by: Jan Rinze <janrinze@gmail.com>
    Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
    Cc: Rabin Vincent <rabin.vincent@stericsson.com>
    Cc: Adrian Bunk <adrian.bunk@movial.com>
    Cc: Rob Herring <robherring2@gmail.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Tested-by: Robert Marklund <robert.marklund@stericsson.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3fa539e24c5d7077791a1d6bd8bb28bf86bef932
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Fri Jul 26 00:08:25 2013 +0200

    m68k/atari: ARAnyM - Fix NatFeat module support

    commit e8184e10f89736a23ea6eea8e24cd524c5c513d2 upstream.

    As pointed out by Andreas Schwab, pointers passed to ARAnyM NatFeat calls
    should be physical addresses, not virtual addresses.

    Fortunately on Atari, physical and virtual kernel addresses are the same,
    as long as normal kernel memory is concerned, so this usually worked fine
    without conversion.

    But for modules, pointers to literal strings are located in vmalloc()ed
    memory. Depending on the version of ARAnyM, this causes the nf_get_id()
    call to just fail, or worse, crash ARAnyM itself with e.g.

        Gotcha! Illegal memory access. Atari PC = $968c

    This is a big issue for distro kernels, who want to have all drivers as
    loadable modules in an initrd.

    Add a wrapper for nf_get_id() that copies the literal to the stack to
    work around this issue.

    Reported-by: Thorsten Glaser <tg@debian.org>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc1e43e5cbee9f14ee940044d0e4e722370009d2
Author: Anton Blanchard <anton@samba.org>
Date:   Thu Jun 30 13:55:27 2011 +0000

    powerpc: Use -mtraceback=no

    commit af9719c3062dfe216a0c3de3fa52be6d22b4456c upstream.

    gcc 4.7 will be more strict about parsing the -mtraceback option:

     gcc: error: unrecognized argument in option '-mtraceback=none'
     gcc: note: valid arguments to '-mtraceback=' are: full no part

    gcc used to do a 2 char compare so both "no" and "none" would
    match. Switch to using -mtraceback=no should work everywhere.

    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a2f18948f8e7ef5b90c654c09e237027e1e0645
Author: David S. Miller <davem@davemloft.net>
Date:   Sat May 19 15:27:01 2012 -0700

    sparc32: Add ucmpdi2.o to obj-y instead of lib-y.

    commit 74c7b28953d4eaa6a479c187aeafcfc0280da5e8 upstream.

    Otherwise if no references exist in the static kernel image,
    we won't export the symbol properly to modules.

    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec982038bd3b0620090e80075be2b5bb5dd26872
Author: Sam Ravnborg <sam@ravnborg.org>
Date:   Sat May 19 11:54:11 2012 +0200

    sparc32: add ucmpdi2

    commit de36e66d5fa52bc6e2dacd95c701a1762b5308a7 upstream.

    Based on copy from microblaze add ucmpdi2 implementation.
    This fixes build of niu driver which failed with:

    drivers/built-in.o: In function `niu_get_nfc':
    niu.c:(.text+0x91494): undefined reference to `__ucmpdi2'

    This driver will never be used on a sparc32 system,
    but patch added to fix build breakage with all*config builds.

    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d808cb7d6aacff9e39d6d1a4e4ad54ad0a47e901
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Aug 13 13:27:34 2013 +0200

    USB: mos7720: fix broken control requests

    commit ef6c8c1d733e244f0499035be0dabe1f4ed98c6f upstream.

    The parallel-port code of the drivers used a stack allocated
    control-request buffer for asynchronous (and possibly deferred) control
    requests. This not only violates the no-DMA-from-stack requirement but
    could also lead to corrupt control requests being submitted.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc1cabf00e9fd2fbfaf4d4df246f53138ccf3a0d
Author: Oliver Neukum <oneukum@suse.de>
Date:   Wed Aug 14 11:01:46 2013 +0200

    usb: add two quirky touchscreen

    commit 304ab4ab079a8ed03ce39f1d274964a532db036b upstream.

    These devices tend to become unresponsive after S3

    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bba2a9f0d381e510ba32f2f984e5ae1e705c90d1
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Aug 13 09:04:05 2013 +0200

    genetlink: fix family dump race

    commit 58ad436fcf49810aa006016107f494c9ac9013db upstream.

    When dumping generic netlink families, only the first dump call
    is locked with genl_lock(), which protects the list of families,
    and thus subsequent calls can access the data without locking,
    racing against family addition/removal. This can cause a crash.
    Fix it - the locking needs to be conditional because the first
    time around it's already locked.

    A similar bug was reported to me on an old kernel (3.4.47) but
    the exact scenario that happened there is no longer possible,
    on those kernels the first round wasn't locked either. Looking
    at the current code I found the race described above, which had
    also existed on the old kernel.

    Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e00f3fdc81f21fe6de883c647aff2efcd6945de4
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Mon Feb 18 16:24:20 2013 +0100

    af_key: initialize satype in key_notify_policy_flush()

    commit 85dfb745ee40232876663ae206cba35f24ab2a40 upstream.

    This field was left uninitialized. Some user daemons perform check against this
    field.

    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: Luis Henriques <luis.henriques@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd874f70e245977197782bc0e03c658f3e93573b
Author: Jesper Nilsson <jesper.nilsson@axis.com>
Date:   Mon Oct 24 11:19:25 2011 +0200

    CRIS: Add _sdata to vmlinux.lds.S

    commit 473e162eea465e60578edb93341752e7f1c1dacc upstream.

    Fixes link error:
      LD      vmlinux
    kernel/built-in.o: In function `core_kernel_data':
    (.text+0x13e44): undefined reference to `_sdata'

    Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 481101ccce3d7cb2247ff29fc7b8ae1916deeae4
Author: Zhang Yi <wetpzy@gmail.com>
Date:   Tue Jun 25 21:19:31 2013 +0800

    futex: Take hugepages into account when generating futex_key

    commit 13d60f4b6ab5b702dc8d2ee20999f98a93728aec upstream.

    The futex_keys of process shared futexes are generated from the page
    offset, the mapping host and the mapping index of the futex user space
    address. This should result in an unique identifier for each futex.

    Though this is not true when futexes are located in different subpages
    of an hugepage. The reason is, that the mapping index for all those
    futexes evaluates to the index of the base page of the hugetlbfs
    mapping. So a futex at offset 0 of the hugepage mapping and another
    one at offset PAGE_SIZE of the same hugepage mapping have identical
    futex_keys. This happens because the futex code blindly uses
    page->index.

    Steps to reproduce the bug:

    1. Map a file from hugetlbfs. Initialize pthread_mutex1 at offset 0
       and pthread_mutex2 at offset PAGE_SIZE of the hugetlbfs
       mapping.

       The mutexes must be initialized as PTHREAD_PROCESS_SHARED because
       PTHREAD_PROCESS_PRIVATE mutexes are not affected by this issue as
       their keys solely depend on the user space address.

    2. Lock mutex1 and mutex2

    3. Create thread1 and in the thread function lock mutex1, which
       results in thread1 blocking on the locked mutex1.

    4. Create thread2 and in the thread function lock mutex2, which
       results in thread2 blocking on the locked mutex2.

    5. Unlock mutex2. Despite the fact that mutex2 got unlocked, thread2
       still blocks on mutex2 because the futex_key points to mutex1.

    To solve this issue we need to take the normal page index of the page
    which contains the futex into account, if the futex is in an hugetlbfs
    mapping. In other words, we calculate the normal page mapping index of
    the subpage in the hugetlbfs mapping.

    Mappings which are not based on hugetlbfs are not affected and still
    use page->index.

    Thanks to Mel Gorman who provided a patch for adding proper evaluation
    functions to the hugetlbfs code to avoid exposing hugetlbfs specific
    details to the futex code.

    [ tglx: Massaged changelog ]

    Signed-off-by: Zhang Yi <zhang.yi20@zte.com.cn>
    Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
    Tested-by: Ma Chenggong <ma.chenggong@zte.com.cn>
    Reviewed-by: 'Mel Gorman' <mgorman@suse.de>
    Acked-by: 'Darren Hart' <dvhart@linux.intel.com>
    Cc: 'Peter Zijlstra' <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/000101ce71a6%24a83c5880%24f8b50980%24@com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Mike Galbraith <mgalbraith@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.93

commit 77a83f016ce93273734ae6a732737c0d700e8113
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Aug 20 10:23:58 2013 -0700

    Linux 3.0.93

commit f12d8c177c00695eb5c35d132eccd5ffcdaca922
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Aug 20 10:06:19 2013 -0700

    Revert "genetlink: fix family dump race"

    This reverts commit bba2a9f0d381e510ba32f2f984e5ae1e705c90d1 which is
    commit 58ad436fcf49810aa006016107f494c9ac9013db upstream, as there are
    reported problems with it.

    Cc: Johannes Berg <johannes.berg@intel.com>
    Cc: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.94

commit cc540ceeceb321a779b1b5a4224774d83a6f1f1b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Aug 29 09:43:15 2013 -0700

    Linux 3.0.94

commit 43bbe371b28bdcb7367e846d53bf6632a2ab2287
Author: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Date:   Thu Aug 22 17:45:37 2013 +0200

    SCSI: zfcp: fix schedule-inside-lock in scsi_device list loops

    commit 924dd584b198a58aa7cb3efefd8a03326550ce8f upstream.

    BUG: sleeping function called from invalid context at kernel/workqueue.c:2752
    in_atomic(): 1, irqs_disabled(): 1, pid: 360, name: zfcperp0.0.1700
    CPU: 1 Not tainted 3.9.3+ #69
    Process zfcperp0.0.1700 (pid: 360, task: 0000000075b7e080, ksp: 000000007476bc30)
    <snip>
    Call Trace:
    ([<00000000001165de>] show_trace+0x106/0x154)
     [<00000000001166a0>] show_stack+0x74/0xf4
     [<00000000006ff646>] dump_stack+0xc6/0xd4
     [<000000000017f3a0>] __might_sleep+0x128/0x148
     [<000000000015ece8>] flush_work+0x54/0x1f8
     [<00000000001630de>] __cancel_work_timer+0xc6/0x128
     [<00000000005067ac>] scsi_device_dev_release_usercontext+0x164/0x23c
     [<0000000000161816>] execute_in_process_context+0x96/0xa8
     [<00000000004d33d8>] device_release+0x60/0xc0
     [<000000000048af48>] kobject_release+0xa8/0x1c4
     [<00000000004f4bf2>] __scsi_iterate_devices+0xfa/0x130
     [<000003ff801b307a>] zfcp_erp_strategy+0x4da/0x1014 [zfcp]
     [<000003ff801b3caa>] zfcp_erp_thread+0xf6/0x2b0 [zfcp]
     [<000000000016b75a>] kthread+0xf2/0xfc
     [<000000000070c9de>] kernel_thread_starter+0x6/0xc
     [<000000000070c9d8>] kernel_thread_starter+0x0/0xc

    Apparently, the ref_count for some scsi_device drops down to zero,
    triggering device removal through execute_in_process_context(), while
    the lldd error recovery thread iterates through a scsi device list.
    Unfortunately, execute_in_process_context() decides to immediately
    execute that device removal function, instead of scheduling asynchronous
    execution, since it detects process context and thinks it is safe to do
    so. But almost all calls to shost_for_each_device() in our lldd are
    inside spin_lock_irq, even in thread context. Obviously, schedule()
    inside spin_lock_irq sections is a bad idea.

    Change the lldd to use the proper iterator function,
    __shost_for_each_device(), in combination with required locking.

    Occurences that need to be changed include all calls in zfcp_erp.c,
    since those might be executed in zfcp error recovery thread context
    with a lock held.

    Other occurences of shost_for_each_device() in zfcp_fsf.c do not
    need to be changed (no process context, no surrounding locking).

    The problem was introduced in Linux 2.6.37 by commit
    b62a8d9b45b971a67a0f8413338c230e3117dff5
    "[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit".

    Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 374172589a9c99e63c373b1c74588553237a74d3
Author: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Date:   Thu Aug 22 17:45:36 2013 +0200

    SCSI: zfcp: fix lock imbalance by reworking request queue locking

    commit d79ff142624e1be080ad8d09101f7004d79c36e1 upstream.

    This patch adds wait_event_interruptible_lock_irq_timeout(), which is a
    straight-forward descendant of wait_event_interruptible_timeout() and
    wait_event_interruptible_lock_irq().

    The zfcp driver used to call wait_event_interruptible_timeout()
    in combination with some intricate and error-prone locking. Using
    wait_event_interruptible_lock_irq_timeout() as a replacement
    nicely cleans up that locking.

    This rework removes a situation that resulted in a locking imbalance
    in zfcp_qdio_sbal_get():

    BUG: workqueue leaked lock or atomic: events/1/0xffffff00/10
        last function: zfcp_fc_wka_port_offline+0x0/0xa0 [zfcp]

    It was introduced by commit c2af7545aaff3495d9bf9a7608c52f0af86fb194
    "[SCSI] zfcp: Do not wait for SBALs on stopped queue", which had a new
    code path related to ZFCP_STATUS_ADAPTER_QDIOUP that took an early exit
    without a required lock being held. The problem occured when a
    special, non-SCSI I/O request was being submitted in process context,
    when the adapter's queues had been torn down. In this case the bug
    surfaced when the Fibre Channel port connection for a well-known address
    was closed during a concurrent adapter shut-down procedure, which is a
    rare constellation.

    This patch also fixes these warnings from the sparse tool (make C=1):

    drivers/s390/scsi/zfcp_qdio.c:224:12: warning: context imbalance in
     'zfcp_qdio_sbal_check' - wrong count at exit
    drivers/s390/scsi/zfcp_qdio.c:244:5: warning: context imbalance in
     'zfcp_qdio_sbal_get' - unexpected unlock

    Last but not least, we get rid of that crappy lock-unlock-lock
    sequence at the beginning of the critical section.

    It is okay to call zfcp_erp_adapter_reopen() with req_q_lock held.

    Reported-by: Mikulas Patocka <mpatocka@redhat.com>
    Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 016d826cfcb22b27915149aabadf461641b7907c
Author: Terry Suereth <terry.suereth@gmail.com>
Date:   Sat Aug 17 15:53:12 2013 -0400

    libata: apply behavioral quirks to sil3826 PMP

    commit 8ffff94d20b7eb446e848e0046107d51b17a20a8 upstream.

    Fixing support for the Silicon Image 3826 port multiplier, by applying
    to it the same quirks applied to the Silicon Image 3726.  Specifically
    fixes the repeated timeout/reset process which previously afflicted
    the 3726, as described from line 290.  Slightly based on notes from:

    https://bugzilla.redhat.com/show_bug.cgi?id=890237

    Signed-off-by: Terry Suereth <terry.suereth@gmail.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d43271717d467f6795cfc5a81fd2cd886833330
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Aug 9 12:52:31 2013 +0300

    Hostap: copying wrong data prism2_ioctl_giwaplist()

    commit 909bd5926d474e275599094acad986af79671ac9 upstream.

    We want the data stored in "addr" and "qual", but the extra ampersands
    mean we are copying stack data instead.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c6766ab27147383b3a084d29cb87163342f14b0
Author: Vyacheslav Dubeyko <slava@dubeyko.com>
Date:   Thu Aug 22 16:35:45 2013 -0700

    nilfs2: fix issue with counting number of bio requests for BIO_EOPNOTSUPP error detection

    commit 4bf93b50fd04118ac7f33a3c2b8a0a1f9fa80bc9 upstream.

    Fix the issue with improper counting number of flying bio requests for
    BIO_EOPNOTSUPP error detection case.

    The sb_nbio must be incremented exactly the same number of times as
    complete() function was called (or will be called) because
    nilfs_segbuf_wait() will call wail_for_completion() for the number of
    times set to sb_nbio:

      do {
          wait_for_completion(&segbuf->sb_bio_event);
      } while (--segbuf->sb_nbio > 0);

    Two functions complete() and wait_for_completion() must be called the
    same number of times for the same sb_bio_event.  Otherwise,
    wait_for_completion() will hang or leak.

    Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    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@linuxfoundation.org>

commit 637a641c5478377849d936fa276f92a4f418bb65
Author: Vyacheslav Dubeyko <slava@dubeyko.com>
Date:   Thu Aug 22 16:35:44 2013 -0700

    nilfs2: remove double bio_put() in nilfs_end_bio_write() for BIO_EOPNOTSUPP error

    commit 2df37a19c686c2d7c4e9b4ce1505b5141e3e5552 upstream.

    Remove double call of bio_put() in nilfs_end_bio_write() for the case of
    BIO_EOPNOTSUPP error detection.  The issue was found by Dan Carpenter
    and he suggests first version of the fix too.

    Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    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@linuxfoundation.org>

commit 14c3de73b19d1c758ae92ec4674482742ad54fb3
Author: Wladislav Wiebe <wladislav.kw@gmail.com>
Date:   Mon Aug 12 13:06:53 2013 +0200

    of: fdt: fix memory initialization for expanded DT

    commit 9e40127526e857fa3f29d51e83277204fbdfc6ba upstream.

    Already existing property flags are filled wrong for properties created from
    initial FDT. This could cause problems if this DYNAMIC device-tree functions
    are used later, i.e. properties are attached/detached/replaced. Simply dumping
    flags from the running system show, that some initial static (not allocated via
    kzmalloc()) nodes are marked as dynamic.

    I putted some debug extensions to property_proc_show(..) :
    ..
    +       if (OF_IS_DYNAMIC(pp))
    +               pr_err("DEBUG: xxx : OF_IS_DYNAMIC\n");
    +       if (OF_IS_DETACHED(pp))
    +               pr_err("DEBUG: xxx : OF_IS_DETACHED\n");

    when you operate on the nodes (e.g.: ~$ cat /proc/device-tree/*some_node*) you
    will see that those flags are filled wrong, basically in most cases it will dump
    a DYNAMIC or DETACHED status, which is in not true.
    (BTW. this OF_IS_DETACHED is a own define for debug purposes which which just
    make a test_bit(OF_DETACHED, &x->_flags)

    If nodes are dynamic kernel is allowed to kfree() them. But it will crash
    attempting to do so on the nodes from FDT -- they are not allocated via
    kzmalloc().

    Signed-off-by: Wladislav Wiebe <wladislav.kw@gmail.com>
    Acked-by: Alexander Sverdlin <alexander.sverdlin@nsn.com>
    Signed-off-by: Rob Herring <rob.herring@calxeda.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b9ba06c5f4e84b8dfa402bee0daff42db045977
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Thu Aug 15 13:21:06 2013 +0100

    xen/events: initialize local per-cpu mask for all possible events

    commit 84ca7a8e45dafb49cd5ca90a343ba033e2885c17 upstream.

    The sizeof() argument in init_evtchn_cpu_bindings() is incorrect
    resulting in only the first 64 (or 32 in 32-bit guests) ports having
    their bindings being initialized to VCPU 0.

    In most cases this does not cause a problem as request_irq() will set
    the irq affinity which will set the correct local per-cpu mask.
    However, if the request_irq() is called on a VCPU other than 0, there
    is a window between the unmasking of the event and the affinity being
    set were an event may be lost because it is not locally unmasked on
    any VCPU. If request_irq() is called on VCPU 0 then local irqs are
    disabled during the window and the race does not occur.

    Fix this by initializing all NR_EVENT_CHANNEL bits in the local
    per-cpu masks.

    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50e27a160f6146de036e81420dc13ec9f4824564
Author: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Date:   Tue Aug 6 14:28:42 2013 +0300

    zd1201: do not use stack as URB transfer_buffer

    commit 1206ff4ff9d2ef7468a355328bc58ac6ebf5be44 upstream.

    Patch fixes zd1201 not to use stack as URB transfer_buffer. URB buffers need
    to be DMA-able, which stack is not.

    Patch is only compile tested.

    Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge branch 'cm-10.1-wip' of git://github.com/Mustaavalkosta/htc7x30-3.0 into rs-dev