Permalink
Commits on Oct 21, 2012
  1. Linux 3.0.47

    gregkh committed Oct 21, 2012
  2. ALSA: emu10k1: add chip details for E-mu 1010 PCIe card

    commit 10f571d upstream.
    
    Add chip details for E-mu 1010 PCIe card. It has the same
    chip as found in E-mu 1010b but it uses different PCI id.
    
    Signed-off-by: Maxim Kachur <mcdebugger@duganet.ru>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    mcdebugger committed with gregkh Oct 17, 2012
  3. ALSA: ac97 - Fix missing NULL check in snd_ac97_cvol_new()

    commit 733a48e upstream.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=44721
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    tiwai committed with gregkh Oct 11, 2012
  4. udf: fix retun value on error path in udf_load_logicalvol

    commit 68766a2 upstream.
    
    In case we detect a problem and bail out, we fail to set "ret" to a
    nonzero value, and udf_load_logicalvol will mistakenly report success.
    
    Signed-off-by: Nikola Pajkovsky <npajkovs@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Nikola Pajkovsky committed with gregkh Aug 14, 2012
  5. tpm: Propagate error from tpm_transmit to fix a timeout hang

    commit abce9ac upstream.
    
    tpm_write calls tpm_transmit without checking the return value and
    assigns the return value unconditionally to chip->pending_data, even if
    it's an error value.
    This causes three bugs.
    
    So if we write to /dev/tpm0 with a tpm_param_size bigger than
    TPM_BUFSIZE=0x1000 (e.g. 0x100a)
    and a bufsize also bigger than TPM_BUFSIZE (e.g. 0x100a)
    tpm_transmit returns -E2BIG which is assigned to chip->pending_data as
    -7, but tpm_write returns that TPM_BUFSIZE bytes have been successfully
    been written to the TPM, altough this is not true (bug #1).
    
    As we did write more than than TPM_BUFSIZE bytes but tpm_write reports
    that only TPM_BUFSIZE bytes have been written the vfs tries to write
    the remaining bytes (in this case 10 bytes) to the tpm device driver via
    tpm_write which then blocks at
    
     /* cannot perform a write until the read has cleared
     either via tpm_read or a user_read_timer timeout */
     while (atomic_read(&chip->data_pending) != 0)
    	 msleep(TPM_TIMEOUT);
    
    for 60 seconds, since data_pending is -7 and nobody is able to
    read it (since tpm_read luckily checks if data_pending is greater than
    0) (#bug 2).
    
    After that the remaining bytes are written to the TPM which are
    interpreted by the tpm as a normal command. (bug #3)
    So if the last bytes of the command stream happen to be a e.g.
    tpm_force_clear this gets accidentally sent to the TPM.
    
    This patch fixes all three bugs, by propagating the error code of
    tpm_write and returning -E2BIG if the input buffer is too big,
    since the response from the tpm for a truncated value is bogus anyway.
    Moreover it returns -EBUSY to userspace if there is a response ready to be
    read.
    
    Signed-off-by: Peter Huewe <peter.huewe@infineon.com>
    Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    PeterHueweIFX committed with gregkh Sep 27, 2012
  6. x86, random: Verify RDRAND functionality and allow it to be disabled

    commit 49d859d upstream.
    
    If the CPU declares that RDRAND is available, go through a guranteed
    reseed sequence, and make sure that it is actually working (producing
    data.)   If it does not, disable the CPU feature flag.
    
    Allow RDRAND to be disabled on the command line (as opposed to at
    compile time) for a user who has special requirements with regards to
    random numbers.
    
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Matt Mackall <mpm@selenic.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    H. Peter Anvin committed with gregkh Jul 31, 2011
  7. x86, random: Architectural inlines to get random integers with RDRAND

    commit 628c624 upstream.
    
    Architectural inlines to get random ints and longs using the RDRAND
    instruction.
    
    Intel has introduced a new RDRAND instruction, a Digital Random Number
    Generator (DRNG), which is functionally an high bandwidth entropy
    source, cryptographic whitener, and integrity monitor all built into
    hardware.  This enables RDRAND to be used directly, bypassing the
    kernel random number pool.
    
    For technical documentation, see:
    
    http://software.intel.com/en-us/articles/download-the-latest-bull-mountain-software-implementation-guide/
    
    In this patch, this is *only* used for the nonblocking random number
    pool.  RDRAND is a nonblocking source, similar to our /dev/urandom,
    and is therefore not a direct replacement for /dev/random.  The
    architectural hooks presented in the previous patch only feed the
    kernel internal users, which only use the nonblocking pool, and so
    this is not a problem.
    
    Since this instruction is available in userspace, there is no reason
    to have a /dev/hw_rng device driver for the purpose of feeding rngd.
    This is especially so since RDRAND is a nonblocking source, and needs
    additional whitening and reduction (see the above technical
    documentation for details) in order to be of "pure entropy source"
    quality.
    
    The CONFIG_EXPERT compile-time option can be used to disable this use
    of RDRAND.
    
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Originally-by: Fenghua Yu <fenghua.yu@intel.com>
    Cc: Matt Mackall <mpm@selenic.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    H. Peter Anvin committed with gregkh Jul 31, 2011
  8. jbd: Fix assertion failure in commit code due to lacking transaction …

    …credits
    
    commit 09e05d4 upstream.
    
    ext3 users of data=journal mode with blocksize < pagesize were occasionally
    hitting assertion failure in journal_commit_transaction() checking whether the
    transaction has at least as many credits reserved as buffers attached.  The
    core of the problem is that when a file gets truncated, buffers that still need
    checkpointing or that are attached to the committing transaction are left with
    buffer_mapped set. When this happens to buffers beyond i_size attached to a
    page stradding i_size, subsequent write extending the file will see these
    buffers and as they are mapped (but underlying blocks were freed) things go
    awry from here.
    
    The assertion failure just coincidentally (and in this case luckily as we would
    start corrupting filesystem) triggers due to journal_head not being properly
    cleaned up as well.
    
    Under some rare circumstances this bug could even hit data=ordered mode users.
    There the assertion won't trigger and we would end up corrupting the
    filesystem.
    
    We fix the problem by unmapping buffers if possible (in lots of cases we just
    need a buffer attached to a transaction as a place holder but it must not be
    written out anyway). And in one case, we just have to bite the bullet and wait
    for transaction commit to finish.
    
    Reviewed-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    jankara committed with gregkh Jul 11, 2012
  9. drm/radeon: Don't destroy I2C Bus Rec in radeon_ext_tmds_enc_destroy().

    commit 0829184 upstream.
    
    radeon_i2c_fini() walks thru the list of I2C bus recs rdev->i2c_bus[]
    to destroy each of them.
    radeon_ext_tmds_enc_destroy() however also has code to destroy it's
    associated I2C bus rec which has been obtained by radeon_i2c_lookup()
    and is therefore also in the i2c_bus[] list.
    This causes a double free resulting in a kernel panic when unloading
    the radeon driver.
    Removing destroy code from radeon_ext_tmds_enc_destroy() fixes this
    problem.
    
    agd5f: fix compiler warning
    
    Signed-off-by: Egbert Eich <eich@suse.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    e4t committed with gregkh Oct 15, 2012
  10. Add CDC-ACM support for the CX93010-2x UCMxx USB Modem

    commit e7d491a upstream.
    
    This USB V.92/V.32bis Controllered Modem have the USB vendor ID 0x0572
    and device ID 0x1340. It need the NO_UNION_NORMAL quirk to be recognized.
    
    Reference:
    http://www.conexant.com/servlets/DownloadServlet/DSH-201723-005.pdf?docid=1725&revid=5
    See idVendor and idProduct in table 6-1. Device Descriptors
    
    Signed-off-by: Jean-Christian de Rivaz <jc@eclis.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    jcdr committed with gregkh Oct 10, 2012
  11. netfilter: xt_limit: have r->cost != 0 case work

    commit 82e6bfe upstream.
    
    Commit v2.6.19-rc1~1272^2~41 tells us that r->cost != 0 can happen when
    a running state is saved to userspace and then reinstated from there.
    
    Make sure that private xt_limit area is initialized with correct values.
    Otherwise, random matchings due to use of uninitialized memory.
    
    Signed-off-by: Jan Engelhardt <jengelh@inai.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    jengelh committed with gregkh Sep 21, 2012
  12. netfilter: limit, hashlimit: avoid duplicated inline

    commit 7a909ac upstream.
    
    credit_cap can be set to credit, which avoids inlining user2credits
    twice. Also, remove inline keyword and let compiler decide.
    
    old:
        684     192       0     876     36c net/netfilter/xt_limit.o
       4927     344      32    5303    14b7 net/netfilter/xt_hashlimit.o
    now:
        668     192       0     860     35c net/netfilter/xt_limit.o
       4793     344      32    5169    1431 net/netfilter/xt_hashlimit.o
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Florian Westphal committed with gregkh May 7, 2012
  13. netfilter: nf_ct_expect: fix possible access to uninitialized timer

    commit 2614f86 upstream.
    
    In __nf_ct_expect_check, the function refresh_timer returns 1
    if a matching expectation is found and its timer is successfully
    refreshed. This results in nf_ct_expect_related returning 0.
    Note that at this point:
    
    - the passed expectation is not inserted in the expectation table
      and its timer was not initialized, since we have refreshed one
      matching/existing expectation.
    
    - nf_ct_expect_alloc uses kmem_cache_alloc, so the expectation
      timer is in some undefined state just after the allocation,
      until it is appropriately initialized.
    
    This can be a problem for the SIP helper during the expectation
    addition:
    
     ...
     if (nf_ct_expect_related(rtp_exp) == 0) {
             if (nf_ct_expect_related(rtcp_exp) != 0)
                     nf_ct_unexpect_related(rtp_exp);
     ...
    
    Note that nf_ct_expect_related(rtp_exp) may return 0 for the timer refresh
    case that is detailed above. Then, if nf_ct_unexpect_related(rtcp_exp)
    returns != 0, nf_ct_unexpect_related(rtp_exp) is called, which does:
    
     spin_lock_bh(&nf_conntrack_lock);
     if (del_timer(&exp->timeout)) {
             nf_ct_unlink_expect(exp);
             nf_ct_expect_put(exp);
     }
     spin_unlock_bh(&nf_conntrack_lock);
    
    Note that del_timer always returns false if the timer has been
    initialized.  However, the timer was not initialized since setup_timer
    was not called, therefore, the expectation timer remains in some
    undefined state. If I'm not missing anything, this may lead to the
    removal an unexistent expectation.
    
    To fix this, the optimization that allows refreshing an expectation
    is removed. Now nf_conntrack_expect_related looks more consistent
    to me since it always add the expectation in case that it returns
    success.
    
    Thanks to Patrick McHardy for participating in the discussion of
    this patch.
    
    I think this may be the source of the problem described by:
    http://marc.info/?l=netfilter-devel&m=134073514719421&w=2
    
    Reported-by: Rafal Fitt <rafalf@aplusc.com.pl>
    Acked-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Pablo Neira Ayuso committed with gregkh Aug 16, 2012
  14. netfilter: nf_nat_sip: fix via header translation with multiple param…

    …eters
    
    commit f22eb25 upstream.
    
    Via-headers are parsed beginning at the first character after the Via-address.
    When the address is translated first and its length decreases, the offset to
    start parsing at is incorrect and header parameters might be missed.
    
    Update the offset after translating the Via-address to fix this.
    
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    kaber committed with gregkh Aug 9, 2012
  15. ipvs: fix oops on NAT reply in br_nf context

    commit 9e33ce4 upstream.
    
    IPVS should not reset skb->nf_bridge in FORWARD hook
    by calling nf_reset for NAT replies. It triggers oops in
    br_nf_forward_finish.
    
    [  579.781508] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
    [  579.781669] IP: [<ffffffff817b1ca5>] br_nf_forward_finish+0x58/0x112
    [  579.781792] PGD 218f9067 PUD 0
    [  579.781865] Oops: 0000 [#1] SMP
    [  579.781945] CPU 0
    [  579.781983] Modules linked in:
    [  579.782047]
    [  579.782080]
    [  579.782114] Pid: 4644, comm: qemu Tainted: G        W    3.5.0-rc5-00006-g95e69f9 #282 Hewlett-Packard  /30E8
    [  579.782300] RIP: 0010:[<ffffffff817b1ca5>]  [<ffffffff817b1ca5>] br_nf_forward_finish+0x58/0x112
    [  579.782455] RSP: 0018:ffff88007b003a98  EFLAGS: 00010287
    [  579.782541] RAX: 0000000000000008 RBX: ffff8800762ead00 RCX: 000000000001670a
    [  579.782653] RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff8800762ead00
    [  579.782845] RBP: ffff88007b003ac8 R08: 0000000000016630 R09: ffff88007b003a90
    [  579.782957] R10: ffff88007b0038e8 R11: ffff88002da37540 R12: ffff88002da01a02
    [  579.783066] R13: ffff88002da01a80 R14: ffff88002d83c000 R15: ffff88002d82a000
    [  579.783177] FS:  0000000000000000(0000) GS:ffff88007b000000(0063) knlGS:00000000f62d1b70
    [  579.783306] CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
    [  579.783395] CR2: 0000000000000004 CR3: 00000000218fe000 CR4: 00000000000027f0
    [  579.783505] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  579.783684] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [  579.783795] Process qemu (pid: 4644, threadinfo ffff880021b20000, task ffff880021aba760)
    [  579.783919] Stack:
    [  579.783959]  ffff88007693cedc ffff8800762ead00 ffff88002da01a02 ffff8800762ead00
    [  579.784110]  ffff88002da01a02 ffff88002da01a80 ffff88007b003b18 ffffffff817b26c7
    [  579.784260]  ffff880080000000 ffffffff81ef59f0 ffff8800762ead00 ffffffff81ef58b0
    [  579.784477] Call Trace:
    [  579.784523]  <IRQ>
    [  579.784562]
    [  579.784603]  [<ffffffff817b26c7>] br_nf_forward_ip+0x275/0x2c8
    [  579.784707]  [<ffffffff81704b58>] nf_iterate+0x47/0x7d
    [  579.784797]  [<ffffffff817ac32e>] ? br_dev_queue_push_xmit+0xae/0xae
    [  579.784906]  [<ffffffff81704bfb>] nf_hook_slow+0x6d/0x102
    [  579.784995]  [<ffffffff817ac32e>] ? br_dev_queue_push_xmit+0xae/0xae
    [  579.785175]  [<ffffffff8187fa95>] ? _raw_write_unlock_bh+0x19/0x1b
    [  579.785179]  [<ffffffff817ac417>] __br_forward+0x97/0xa2
    [  579.785179]  [<ffffffff817ad366>] br_handle_frame_finish+0x1a6/0x257
    [  579.785179]  [<ffffffff817b2386>] br_nf_pre_routing_finish+0x26d/0x2cb
    [  579.785179]  [<ffffffff817b2cf0>] br_nf_pre_routing+0x55d/0x5c1
    [  579.785179]  [<ffffffff81704b58>] nf_iterate+0x47/0x7d
    [  579.785179]  [<ffffffff817ad1c0>] ? br_handle_local_finish+0x44/0x44
    [  579.785179]  [<ffffffff81704bfb>] nf_hook_slow+0x6d/0x102
    [  579.785179]  [<ffffffff817ad1c0>] ? br_handle_local_finish+0x44/0x44
    [  579.785179]  [<ffffffff81551525>] ? sky2_poll+0xb35/0xb54
    [  579.785179]  [<ffffffff817ad62a>] br_handle_frame+0x213/0x229
    [  579.785179]  [<ffffffff817ad417>] ? br_handle_frame_finish+0x257/0x257
    [  579.785179]  [<ffffffff816e3b47>] __netif_receive_skb+0x2b4/0x3f1
    [  579.785179]  [<ffffffff816e69fc>] process_backlog+0x99/0x1e2
    [  579.785179]  [<ffffffff816e6800>] net_rx_action+0xdf/0x242
    [  579.785179]  [<ffffffff8107e8a8>] __do_softirq+0xc1/0x1e0
    [  579.785179]  [<ffffffff8135a5ba>] ? trace_hardirqs_off_thunk+0x3a/0x6c
    [  579.785179]  [<ffffffff8188812c>] call_softirq+0x1c/0x30
    
    The steps to reproduce as follow,
    
    1. On Host1, setup brige br0(192.168.1.106)
    2. Boot a kvm guest(192.168.1.105) on Host1 and start httpd
    3. Start IPVS service on Host1
       ipvsadm -A -t 192.168.1.106:80 -s rr
       ipvsadm -a -t 192.168.1.106:80 -r 192.168.1.105:80 -m
    4. Run apache benchmark on Host2(192.168.1.101)
       ab -n 1000 http://192.168.1.106/
    
    ip_vs_reply4
      ip_vs_out
        handle_response
          ip_vs_notrack
            nf_reset()
            {
              skb->nf_bridge = NULL;
            }
    
    Actually, IPVS wants in this case just to replace nfct
    with untracked version. So replace the nf_reset(skb) call
    in ip_vs_notrack() with a nf_conntrack_put(skb->nfct) call.
    
    Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Lin Ming committed with gregkh Jul 7, 2012
  16. netfilter: nf_nat_sip: fix incorrect handling of EBUSY for RTCP expec…

    …tation
    
    commit 3f509c6 upstream.
    
    We're hitting bug while trying to reinsert an already existing
    expectation:
    
    kernel BUG at kernel/timer.c:895!
    invalid opcode: 0000 [#1] SMP
    [...]
    Call Trace:
     <IRQ>
     [<ffffffffa0069563>] nf_ct_expect_related_report+0x4a0/0x57a [nf_conntrack]
     [<ffffffff812d423a>] ? in4_pton+0x72/0x131
     [<ffffffffa00ca69e>] ip_nat_sdp_media+0xeb/0x185 [nf_nat_sip]
     [<ffffffffa00b5b9b>] set_expected_rtp_rtcp+0x32d/0x39b [nf_conntrack_sip]
     [<ffffffffa00b5f15>] process_sdp+0x30c/0x3ec [nf_conntrack_sip]
     [<ffffffff8103f1eb>] ? irq_exit+0x9a/0x9c
     [<ffffffffa00ca738>] ? ip_nat_sdp_media+0x185/0x185 [nf_nat_sip]
    
    We have to remove the RTP expectation if the RTCP expectation hits EBUSY
    since we keep trying with other ports until we succeed.
    
    Reported-by: Rafal Fitt <rafalf@aplusc.com.pl>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Pablo Neira Ayuso committed with gregkh Aug 29, 2012
  17. netfilter: nf_ct_ipv4: packets with wrong ihl are invalid

    commit 07153c6 upstream.
    
    It was reported that the Linux kernel sometimes logs:
    
    klogd: [2629147.402413] kernel BUG at net / netfilter /
    nf_conntrack_proto_tcp.c: 447!
    klogd: [1072212.887368] kernel BUG at net / netfilter /
    nf_conntrack_proto_tcp.c: 392
    
    ipv4_get_l4proto() in nf_conntrack_l3proto_ipv4.c and tcp_error() in
    nf_conntrack_proto_tcp.c should catch malformed packets, so the errors
    at the indicated lines - TCP options parsing - should not happen.
    However, tcp_error() relies on the "dataoff" offset to the TCP header,
    calculated by ipv4_get_l4proto().  But ipv4_get_l4proto() does not check
    bogus ihl values in IPv4 packets, which then can slip through tcp_error()
    and get caught at the TCP options parsing routines.
    
    The patch fixes ipv4_get_l4proto() by invalidating packets with bogus
    ihl value.
    
    The patch closes netfilter bugzilla id 771.
    
    Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Jozsef Kadlecsik committed with gregkh Apr 3, 2012
  18. netfilter: nf_conntrack: fix racy timer handling with reliable events

    commit 5b423f6 upstream.
    
    Existing code assumes that del_timer returns true for alive conntrack
    entries. However, this is not true if reliable events are enabled.
    In that case, del_timer may return true for entries that were
    just inserted in the dying list. Note that packets / ctnetlink may
    hold references to conntrack entries that were just inserted to such
    list.
    
    This patch fixes the issue by adding an independent timer for
    event delivery. This increases the size of the ecache extension.
    Still we can revisit this later and use variable size extensions
    to allocate this area on demand.
    
    Tested-by: Oliver Smith <olipro@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Pablo Neira Ayuso committed with gregkh Aug 29, 2012
  19. ipvs: fix oops in ip_vs_dst_event on rmmod

    commit 283283c upstream.
    
    	After commit 39f618b (3.4)
    "ipvs: reset ipvs pointer in netns" we can oops in
    ip_vs_dst_event on rmmod ip_vs because ip_vs_control_cleanup
    is called after the ipvs_core_ops subsys is unregistered and
    net->ipvs is NULL. Fix it by exiting early from ip_vs_dst_event
    if ipvs is NULL. It is safe because all services and dests
    for the net are already freed.
    
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Julian Anastasov committed with gregkh Jul 7, 2012
  20. tg3: Apply short DMA frag workaround to 5906

    commit b7abee6 upstream.
    
    5906 devices also need the short DMA fragment workaround.  This patch
    makes the necessary change.
    
    Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
    Tested-by: Christian Kujau <lists@nerdbynature.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Mike Pagano <mpagano@gentoo.org>
    Matt Carlson committed with gregkh Jun 7, 2012
  21. pktgen: fix crash when generating IPv6 packets

    commit 5aa8b57 upstream.
    
    For IPv6, sizeof(struct ipv6hdr) = 40, thus the following
    expression will result negative:
    
            datalen = pkt_dev->cur_pkt_size - 14 -
                      sizeof(struct ipv6hdr) - sizeof(struct udphdr) -
                      pkt_dev->pkt_overhead;
    
    And,  the check "if (datalen < sizeof(struct pktgen_hdr))" will be
    passed as "datalen" is promoted to unsigned, therefore will cause
    a crash later.
    
    This is a quick fix by checking if "datalen" is negative. The following
    patch will increase the default value of 'min_pkt_size' for IPv6.
    
    This bug should exist for a long time, so Cc -stable too.
    
    Signed-off-by: Cong Wang <amwang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Amerigo Wang committed with gregkh Oct 9, 2012
  22. timers: Fix endless looping between cascade() and internal_add_timer()

    commit 26cff4e upstream.
    
    Adding two (or more) timers with large values for "expires" (they have
    to reside within tv5 in the same list) leads to endless looping
    between cascade() and internal_add_timer() in case CONFIG_BASE_SMALL
    is one and jiffies are crossing the value 1 << 18. The bug was
    introduced between 2.6.11 and 2.6.12 (and survived for quite some
    time).
    
    This patch ensures that when cascade() is called timers within tv5 are
    not added endlessly to their own list again, instead they are added to
    the next lower tv level tv4 (as expected).
    
    Signed-off-by: Christian Hildner <christian.hildner@siemens.com>
    Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
    Link: http://lkml.kernel.org/r/98673C87CB31274881CFFE0B65ECC87B0F5FC1963E@DEFTHW99EA4MSX.ww902.siemens.net
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Hildner, Christian committed with gregkh Oct 8, 2012
  23. viafb: don't touch clock state on OLPC XO-1.5

    commit 012a121 upstream.
    
    As detailed in the thread titled "viafb PLL/clock tweaking causes XO-1.5
    instability," enabling or disabling the IGA1/IGA2 clocks causes occasional
    stability problems during suspend/resume cycles on this platform.
    
    This is rather odd, as the documentation suggests that clocks have two
    states (on/off) and the default (stable) configuration is configured to
    enable the clock only when it is needed. However, explicitly enabling *or*
    disabling the clock triggers this system instability, suggesting that there
    is a 3rd state at play here.
    
    Leaving the clock enable/disable registers alone solves this problem.
    This fixes spurious reboots during suspend/resume behaviour introduced by
    commit b692a63.
    
    Signed-off-by: Daniel Drake <dsd@laptop.org>
    Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Daniel Drake committed with gregkh Sep 4, 2012
  24. video/udlfb: fix line counting in fb_write

    commit b8c4321 upstream.
    
    Line 0 and 1 were both written to line 0 (on the display) and all subsequent
    lines had an offset of -1. The result was that the last line on the display
    was never overwritten by writes to /dev/fbN.
    
    Signed-off-by: Alexander Holler <holler@ahsoftware.de>
    Acked-by: Bernie Thompson <bernie@plugable.com>
    Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    aholler committed with gregkh Aug 14, 2012
  25. module: taint kernel when lve module is loaded

    commit c99af37 upstream.
    
    Cloudlinux have a product called lve that includes a kernel module. This
    was previously GPLed but is now under a proprietary license, but the
    module continues to declare MODULE_LICENSE("GPL") and makes use of some
    EXPORT_SYMBOL_GPL symbols. Forcibly taint it in order to avoid this.
    
    Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
    Cc: Alex Lyashkov <umka@cloudlinux.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Matthew Garrett committed with gregkh Jun 22, 2012
  26. autofs4 - fix reset pending flag on mount fail

    commit 49999ab upstream.
    
    In autofs4_d_automount(), if a mount fail occurs the AUTOFS_INF_PENDING
    mount pending flag is not cleared.
    
    One effect of this is when using the "browse" option, directory entry
    attributes show up with all "?"s due to the incorrect callback and
    subsequent failure return (when in fact no callback should be made).
    
    Signed-off-by: Ian Kent <ikent@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    raven-au committed with gregkh Oct 11, 2012
  27. block: fix request_queue->flags initialization

    commit 60ea822 upstream.
    
    A queue newly allocated with blk_alloc_queue_node() has only
    QUEUE_FLAG_BYPASS set.  For request-based drivers,
    blk_init_allocated_queue() is called and q->queue_flags is overwritten
    with QUEUE_FLAG_DEFAULT which doesn't include BYPASS even though the
    initial bypass is still in effect.
    
    In blk_init_allocated_queue(), or QUEUE_FLAG_DEFAULT to q->queue_flags
    instead of overwriting.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Vivek Goyal <vgoyal@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    htejun committed with gregkh Sep 20, 2012
  28. xen/bootup: allow read_tscp call for Xen PV guests.

    commit cd0608e upstream.
    
    The hypervisor will trap it. However without this patch,
    we would crash as the .read_tscp is set to NULL. This patch
    fixes it and sets it to the native_read_tscp call.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Konrad Rzeszutek Wilk committed with gregkh Oct 10, 2012
  29. xen/bootup: allow {read|write}_cr8 pvops call.

    commit 1a7bbda upstream.
    
    We actually do not do anything about it. Just return a default
    value of zero and if the kernel tries to write anything but 0
    we BUG_ON.
    
    This fixes the case when an user tries to suspend the machine
    and it blows up in save_processor_state b/c 'read_cr8' is set
    to NULL and we get:
    
    kernel BUG at /home/konrad/ssd/linux/arch/x86/include/asm/paravirt.h:100!
    invalid opcode: 0000 [#1] SMP
    Pid: 2687, comm: init.late Tainted: G           O 3.6.0upstream-00002-gac264ac-dirty #4 Bochs Bochs
    RIP: e030:[<ffffffff814d5f42>]  [<ffffffff814d5f42>] save_processor_state+0x212/0x270
    
    .. snip..
    Call Trace:
     [<ffffffff810733bf>] do_suspend_lowlevel+0xf/0xac
     [<ffffffff8107330c>] ? x86_acpi_suspend_lowlevel+0x10c/0x150
     [<ffffffff81342ee2>] acpi_suspend_enter+0x57/0xd5
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Konrad Rzeszutek Wilk committed with gregkh Oct 10, 2012
  30. SUNRPC: Ensure that the TCP socket is closed when in CLOSE_WAIT

    commit a519fc7 upstream.
    
    Instead of doing a shutdown() call, we need to do an actual close().
    Ditto if/when the server is sending us junk RPC headers.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Tested-by: Simon Kirby <sim@hostway.ca>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Trond Myklebust committed with gregkh Sep 12, 2012
  31. firewire: cdev: fix user memory corruption (i386 userland on amd64 ke…

    …rnel)
    
    commit 790198f upstream.
    
    Fix two bugs of the /dev/fw* character device concerning the
    FW_CDEV_IOC_GET_INFO ioctl with nonzero fw_cdev_get_info.bus_reset.
    (Practically all /dev/fw* clients issue this ioctl right after opening
    the device.)
    
    Both bugs are caused by sizeof(struct fw_cdev_event_bus_reset) being 36
    without natural alignment and 40 with natural alignment.
    
     1) Memory corruption, affecting i386 userland on amd64 kernel:
        Userland reserves a 36 bytes large buffer, kernel writes 40 bytes.
        This has been first found and reported against libraw1394 if
        compiled with gcc 4.7 which happens to order libraw1394's stack such
        that the bug became visible as data corruption.
    
     2) Information leak, affecting all kernel architectures except i386:
        4 bytes of random kernel stack data were leaked to userspace.
    
    Hence limit the respective copy_to_user() to the 32-bit aligned size of
    struct fw_cdev_event_bus_reset.
    
    Reported-by: Simon Kirby <sim@hostway.ca>
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stefan Richter committed with gregkh Oct 6, 2012
  32. ARM: 7541/1: Add ARM ERRATA 775420 workaround

    commit 7253b85 upstream.
    
    arm: Add ARM ERRATA 775420 workaround
    
    Workaround for the 775420 Cortex-A9 (r2p2, r2p6,r2p8,r2p10,r3p0) erratum.
    In case a date cache maintenance operation aborts with MMU exception, it
    might cause the processor to deadlock. This workaround puts DSB before
    executing ISB if an abort may occur on cache maintenance.
    
    Based on work by Kouei Abe and feedback from Catalin Marinas.
    
    Signed-off-by: Kouei Abe <kouei.abe.cp@rms.renesas.com>
    [ horms@verge.net.au: Changed to implementation
      suggested by catalin.marinas@arm.com ]
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    horms committed with gregkh Sep 28, 2012
  33. tmpfs,ceph,gfs2,isofs,reiserfs,xfs: fix fh_len checking

    commit 35c2a7f upstream.
    
    Fuzzing with trinity oopsed on the 1st instruction of shmem_fh_to_dentry(),
    	u64 inum = fid->raw[2];
    which is unhelpfully reported as at the end of shmem_alloc_inode():
    
    BUG: unable to handle kernel paging request at ffff880061cd3000
    IP: [<ffffffff812190d0>] shmem_alloc_inode+0x40/0x40
    Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
    Call Trace:
     [<ffffffff81488649>] ? exportfs_decode_fh+0x79/0x2d0
     [<ffffffff812d77c3>] do_handle_open+0x163/0x2c0
     [<ffffffff812d792c>] sys_open_by_handle_at+0xc/0x10
     [<ffffffff83a5f3f8>] tracesys+0xe1/0xe6
    
    Right, tmpfs is being stupid to access fid->raw[2] before validating that
    fh_len includes it: the buffer kmalloc'ed by do_sys_name_to_handle() may
    fall at the end of a page, and the next page not be present.
    
    But some other filesystems (ceph, gfs2, isofs, reiserfs, xfs) are being
    careless about fh_len too, in fh_to_dentry() and/or fh_to_parent(), and
    could oops in the same way: add the missing fh_len checks to those.
    
    Reported-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Sage Weil <sage@inktank.com>
    Cc: Steven Whitehouse <swhiteho@redhat.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Hugh Dickins committed with gregkh Oct 8, 2012
  34. mips,kgdb: fix recursive page fault with CONFIG_KPROBES

    commit f0a996e upstream.
    
    This fault was detected using the kgdb test suite on boot and it
    crashes recursively due to the fact that CONFIG_KPROBES on mips adds
    an extra die notifier in the page fault handler.  The crash signature
    looks like this:
    
    kgdbts:RUN bad memory access test
    KGDB: re-enter exception: ALL breakpoints killed
    Call Trace:
    [<807b7548>] dump_stack+0x20/0x54
    [<807b7548>] dump_stack+0x20/0x54
    
    The fix for now is to have kgdb return immediately if the fault type
    is DIE_PAGE_FAULT and allow the kprobe code to decide what is supposed
    to happen.
    
    Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
    Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    jwessel committed with gregkh Aug 10, 2012
  35. ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop

    commit 67bfa9b upstream.
    
    By enlarging the GPE storm threshold back to 20, that laptop's
    EC works fine with interrupt mode instead of polling mode.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=45151
    
    Reported-and-Tested-by: Francesco <trentini@dei.unipd.it>
    Signed-off-by: Feng Tang <feng.tang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    ftang1 committed with gregkh Sep 28, 2012