1. 11 May, 2016 7 commits
    • Dan Streetman's avatar
      nbd: ratelimit error msgs after socket close · be086008
      Dan Streetman authored
      commit da6ccaaa upstream.
      
      Make the "Attempted send on closed socket" error messages generated in
      nbd_request_handler() ratelimited.
      
      When the nbd socket is shutdown, the nbd_request_handler() function emits
      an error message for every request remaining in its queue.  If the queue
      is large, this will spam a large amount of messages to the log.  There's
      no need for a separate error message for each request, so this patch
      ratelimits it.
      
      In the specific case this was found, the system was virtual and the error
      messages were logged to the serial port, which overwhelmed it.
      
      Fixes: 4d48a542 ("nbd: fix I/O hang on disconnected nbds")
      Signed-off-by: default avatarDan Streetman <dan.streetman@canonical.com>
      Signed-off-by: default avatarMarkus Pargmann <mpa@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be086008
    • Andy Shevchenko's avatar
      mfd: intel-lpss: Remove clock tree on error path · 8cc83813
      Andy Shevchenko authored
      commit 84cb36ca upstream.
      
      We forgot to remove the clock tree if something goes wrong in ->probe(). Add a
      call to intel_lpss_unregister_clock() on error path in ->probe() to fix the
      potential issue.
      
      Fixes: 4b45efe8 (mfd: Add support for Intel Sunrisepoint LPSS devices)
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8cc83813
    • Julian Anastasov's avatar
      ipvs: drop first packet to redirect conntrack · f94ad404
      Julian Anastasov authored
      commit f719e375 upstream.
      
      Jiri Bohac is reporting for a problem where the attempt
      to reschedule existing connection to another real server
      needs proper redirect for the conntrack used by the IPVS
      connection. For example, when IPVS connection is created
      to NAT-ed real server we alter the reply direction of
      conntrack. If we later decide to select different real
      server we can not alter again the conntrack. And if we
      expire the old connection, the new connection is left
      without conntrack.
      
      So, the only way to redirect both the IPVS connection and
      the Netfilter's conntrack is to drop the SYN packet that
      hits existing connection, to wait for the next jiffie
      to expire the old connection and its conntrack and to rely
      on client's retransmission to create new connection as
      usually.
      
      Jiri Bohac provided a fix that drops all SYNs on rescheduling,
      I extended his patch to do such drops only for connections
      that use conntrack. Here is the original report from Jiri Bohac:
      
      Since commit dc7b3eb9 ("ipvs: Fix reuse connection if real server
      is dead"), new connections to dead servers are redistributed
      immediately to new servers.  The old connection is expired using
      ip_vs_conn_expire_now() which sets the connection timer to expire
      immediately.
      
      However, before the timer callback, ip_vs_conn_expire(), is run
      to clean the connection's conntrack entry, the new redistributed
      connection may already be established and its conntrack removed
      instead.
      
      Fix this by dropping the first packet of the new connection
      instead, like we do when the destination server is not available.
      The timer will have deleted the old conntrack entry long before
      the first packet of the new connection is retransmitted.
      
      Fixes: dc7b3eb9 ("ipvs: Fix reuse connection if real server is dead")
      Signed-off-by: default avatarJiri Bohac <jbohac@suse.cz>
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f94ad404
    • Marco Angaroni's avatar
      ipvs: correct initial offset of Call-ID header search in SIP persistence engine · ba5e7e67
      Marco Angaroni authored
      commit 7617a24f upstream.
      
      The IPVS SIP persistence engine is not able to parse the SIP header
      "Call-ID" when such header is inserted in the first positions of
      the SIP message.
      
      When IPVS is configured with "--pe sip" option, like for example:
      ipvsadm -A -u 1.2.3.4:5060 -s rr --pe sip -p 120 -o
      some particular messages (see below for details) do not create entries
      in the connection template table, which can be listed with:
      ipvsadm -Lcn --persistent-conn
      
      Problematic SIP messages are SIP responses having "Call-ID" header
      positioned just after message first line:
      SIP/2.0 200 OK
      [Call-ID header here]
      [rest of the headers]
      
      When "Call-ID" header is positioned down (after a few other headers)
      it is correctly recognized.
      
      This is due to the data offset used in get_callid function call inside
      ip_vs_pe_sip.c file: since dptr already points to the start of the
      SIP message, the value of dataoff should be initially 0.
      Otherwise the header is searched starting from some bytes after the
      first character of the SIP message.
      
      Fixes: 758ff033 ("IPVS: sip persistence engine")
      Signed-off-by: default avatarMarco Angaroni <marcoangaroni@gmail.com>
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ba5e7e67
    • Arnd Bergmann's avatar
      ipvs: handle ip_vs_fill_iph_skb_off failure · c6a012ba
      Arnd Bergmann authored
      commit 3f20efba upstream.
      
      ip_vs_fill_iph_skb_off() may not find an IP header, and gcc has
      determined that ip_vs_sip_fill_param() then incorrectly accesses
      the protocol fields:
      
      net/netfilter/ipvs/ip_vs_pe_sip.c: In function 'ip_vs_sip_fill_param':
      net/netfilter/ipvs/ip_vs_pe_sip.c:76:5: error: 'iph.protocol' may be used uninitialized in this function [-Werror=maybe-uninitialized]
        if (iph.protocol != IPPROTO_UDP)
           ^
      net/netfilter/ipvs/ip_vs_pe_sip.c:81:10: error: 'iph.len' may be used uninitialized in this function [-Werror=maybe-uninitialized]
        dataoff = iph.len + sizeof(struct udphdr);
                ^
      
      This adds a check for the ip_vs_fill_iph_skb_off() return code
      before looking at the ip header data returned from it.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: b0e010c5 ("ipvs: replace ip_vs_fill_ip4hdr with ip_vs_fill_iph_skb_off")
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c6a012ba
    • Hariprasad S's avatar
      RDMA/iw_cxgb4: Fix bar2 virt addr calculation for T4 chips · 23493843
      Hariprasad S authored
      commit 32cc92c7 upstream.
      
      For T4, kernel mode qps don't use the user doorbell. User mode qps during
      flow control db ringing are forced into kernel, where user doorbell is
      treated as kernel doorbell and proper bar2 offset in bar2 virtual space is
      calculated, which incase of T4 is a bogus address, causing a kernel panic
      due to illegal write during doorbell ringing.
      In case of T4, kernel mode qp bar2 virtual address should be 0. Added T4
      check during bar2 virtual address calculation to return 0. Fixed Bar2
      range checks based on bar2 physical address.
      
      The below oops will be fixed
      
        <1>BUG: unable to handle kernel paging request at 000000000002aa08
        <1>IP: [<ffffffffa011d800>] c4iw_uld_control+0x4e0/0x880 [iw_cxgb4]
        <4>PGD 1416a8067 PUD 15bf35067 PMD 0
        <4>Oops: 0002 [#1] SMP
        <4>last sysfs file:
        /sys/devices/pci0000:00/0000:00:03.0/0000:02:00.4/infiniband/cxgb4_0/node_guid
        <4>CPU 5
        <4>Modules linked in: rdma_ucm rdma_cm ib_cm ib_sa ib_mad ib_uverbs
        ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE
        iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack
        ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables bridge autofs4
        target_core_iblock target_core_file target_core_pscsi target_core_mod
        configfs bnx2fc cnic uio fcoe libfcoe libfc scsi_transport_fc scsi_tgt 8021q
        garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf vhost_net macvtap
        macvlan tun kvm uinput microcode iTCO_wdt iTCO_vendor_support sg joydev
        serio_raw i2c_i801 i2c_core lpc_ich mfd_core e1000e ptp pps_core ioatdma dca
        i7core_edac edac_core shpchp ext3 jbd mbcache sd_mod crc_t10dif pata_acpi
        ata_generic ata_piix iw_cxgb4 iw_cm ib_core ib_addr cxgb4 ipv6 dm_mirror
        dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
        <4>
        Supermicro X8ST3/X8ST3
        <4>RIP: 0010:[<ffffffffa011d800>]  [<ffffffffa011d800>]
        c4iw_uld_control+0x4e0/0x880 [iw_cxgb4]
        <4>RSP: 0000:ffff880155a03db0  EFLAGS: 00010006
        <4>RAX: 000000000000001d RBX: ffff88013ae5fc00 RCX: ffff880155adb180
        <4>RDX: 000000000002aa00 RSI: 0000000000000001 RDI: ffff88013ae5fdf8
        <4>RBP: ffff880155a03e10 R08: 0000000000000000 R09: 0000000000000001
        <4>R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
        <4>R13: 000000000000001d R14: ffff880156414ab0 R15: ffffe8ffffc05b88
        <4>FS:  0000000000000000(0000) GS:ffff8800282a0000(0000) knlGS:0000000000000000
        <4>CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
        <4>CR2: 000000000002aa08 CR3: 000000015bd0e000 CR4: 00000000000007e0
        <4>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        <4>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
        <4>Process cxgb4 (pid: 394, threadinfo ffff880155a00000, task ffff880156414ab0)
        <4>Stack:
        <4> ffff880156415068 ffff880155adb180 ffff880155a03df0 ffffffffa00a344b
        <4><d> 00000000000003e8 ffff880155920000 0000000000000004 ffff880155920000
        <4><d> ffff88015592d438 ffffffffa00a3860 ffff880155a03fd8 ffffe8ffffc05b88
        <4>Call Trace:
        <4> [<ffffffffa00a344b>] ? enable_txq_db+0x2b/0x80 [cxgb4]
        <4> [<ffffffffa00a3860>] ? process_db_full+0x0/0xa0 [cxgb4]
        <4> [<ffffffffa00a38a6>] process_db_full+0x46/0xa0 [cxgb4]
        <4> [<ffffffff8109fda0>] worker_thread+0x170/0x2a0
        <4> [<ffffffff810a6aa0>] ? autoremove_wake_function+0x0/0x40
        <4> [<ffffffff8109fc30>] ? worker_thread+0x0/0x2a0
        <4> [<ffffffff810a660e>] kthread+0x9e/0xc0
        <4> [<ffffffff8100c28a>] child_rip+0xa/0x20
        <4> [<ffffffff810a6570>] ? kthread+0x0/0xc0
        <4> [<ffffffff8100c280>] ? child_rip+0x0/0x20
        <4>Code: e9 ba 00 00 00 66 0f 1f 44 00 00 44 8b 05 29 07 02 00 45 85 c0 0f 85
        71 02 00 00 8b 83 70 01 00 00 45 0f b7 ed c1 e0 0f 44 09 e8 <89> 42 08 0f ae f8
        66 c7 83 82 01 00 00 00 00 44 0f b7 ab dc 01
        <1>RIP  [<ffffffffa011d800>] c4iw_uld_control+0x4e0/0x880 [iw_cxgb4]
        <4> RSP <ffff880155a03db0>
        <4>CR2: 000000000002aa08`
      
      Based on original work by Bharat Potnuri <bharat@chelsio.com>
      
      Fixes: 74217d4c ("iw_cxgb4: support for bar2 qid densities exceeding the page size")
      Signed-off-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarHariprasad Shenai <hariprasad@chelsio.com>
      Reviewed-by: default avatarLeon Romanovsky <leon@leon.nu>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      23493843
    • Greg Kroah-Hartman's avatar
      Revert: "powerpc/tm: Check for already reclaimed tasks" · a9bd7482
      Greg Kroah-Hartman authored
      This reverts commit e924c60d which was
      commit 7f821fc9 upstream.
      
      It shouldn't have been applied as the original was already in 4.4.
      Reported-by: default avatarJiri Slaby <jslaby@suse.cz>
      Cc: Michael Neuling <mikey@neuling.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a9bd7482
  2. 04 May, 2016 33 commits