<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/infiniband, branch v3.2-rc4</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge branches 'cxgb4', 'ipoib', 'misc' and 'qib' into for-next</title>
<updated>2011-11-30T02:01:53+00:00</updated>
<author>
<name>Roland Dreier</name>
<email>roland@purestorage.com</email>
</author>
<published>2011-11-30T02:01:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a493f1a24a496711d96b91c4dc0a1bd35eb6954b'/>
<id>a493f1a24a496711d96b91c4dc0a1bd35eb6954b</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>IB: Fix RCU lockdep splats</title>
<updated>2011-11-29T21:37:11+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>eric.dumazet@gmail.com</email>
</author>
<published>2011-11-29T21:31:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=580da35a31f91a594f3090b7a2c39b85cb051a12'/>
<id>580da35a31f91a594f3090b7a2c39b85cb051a12</id>
<content type='text'>
Commit f2c31e32b37 ("net: fix NULL dereferences in check_peer_redir()")
forgot to take care of infiniband uses of dst neighbours.

Many thanks to Marc Aurele who provided a nice bug report and feedback.

Reported-by: Marc Aurele La France &lt;tsi@ualberta.ca&gt;
Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Cc: David Miller &lt;davem@davemloft.net&gt;
Cc: &lt;stable@kernel.org&gt;
Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit f2c31e32b37 ("net: fix NULL dereferences in check_peer_redir()")
forgot to take care of infiniband uses of dst neighbours.

Many thanks to Marc Aurele who provided a nice bug report and feedback.

Reported-by: Marc Aurele La France &lt;tsi@ualberta.ca&gt;
Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Cc: David Miller &lt;davem@davemloft.net&gt;
Cc: &lt;stable@kernel.org&gt;
Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>IB/ipoib: Prevent hung task or softlockup processing multicast response</title>
<updated>2011-11-29T21:20:02+00:00</updated>
<author>
<name>Mike Marciniszyn</name>
<email>mike.marciniszyn@qlogic.com</email>
</author>
<published>2011-11-21T13:43:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3874397c0bdec3c21ce071711cd105165179b8eb'/>
<id>3874397c0bdec3c21ce071711cd105165179b8eb</id>
<content type='text'>
This following can occur with ipoib when processing a multicast reponse:

    BUG: soft lockup - CPU#0 stuck for 67s! [ib_mad1:982]
    Modules linked in: ...
    CPU 0:
    Modules linked in: ...
    Pid: 982, comm: ib_mad1 Not tainted 2.6.32-131.0.15.el6.x86_64 #1 ProLiant DL160 G5
    RIP: 0010:[&lt;ffffffff814ddb27&gt;]  [&lt;ffffffff814ddb27&gt;] _spin_unlock_irqrestore+0x17/0x20
    RSP: 0018:ffff8802119ed860  EFLAGS: 00000246
    0000000000000004 RBX: ffff8802119ed860 RCX: 000000000000a299
    RDX: ffff88021086c700 RSI: 0000000000000246 RDI: 0000000000000246
    RBP: ffffffff8100bc8e R08: ffff880210ac229c R09: 0000000000000000
    R10: ffff88021278aab8 R11: 0000000000000000 R12: ffff8802119ed860
    R13: ffffffff8100be6e R14: 0000000000000001 R15: 0000000000000003
    FS:  0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    CR2: 00000000006d4840 CR3: 0000000209aa5000 CR4: 00000000000406f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Call Trace:
    [&lt;ffffffffa032c247&gt;] ? ipoib_mcast_send+0x157/0x480 [ib_ipoib]
    [&lt;ffffffff8100bc8e&gt;] ? apic_timer_interrupt+0xe/0x20
    [&lt;ffffffff8100bc8e&gt;] ? apic_timer_interrupt+0xe/0x20
    [&lt;ffffffffa03283d4&gt;] ? ipoib_path_lookup+0x124/0x2d0 [ib_ipoib]
    [&lt;ffffffffa03286fc&gt;] ? ipoib_start_xmit+0x17c/0x430 [ib_ipoib]
    [&lt;ffffffff8141e758&gt;] ? dev_hard_start_xmit+0x2c8/0x3f0
    [&lt;ffffffff81439d0a&gt;] ? sch_direct_xmit+0x15a/0x1c0
    [&lt;ffffffff81423098&gt;] ? dev_queue_xmit+0x388/0x4d0
    [&lt;ffffffffa032d6b7&gt;] ? ipoib_mcast_join_finish+0x2c7/0x510 [ib_ipoib]
    [&lt;ffffffffa032dab8&gt;] ? ipoib_mcast_sendonly_join_complete+0x1b8/0x1f0 [ib_ipoib]
    [&lt;ffffffffa02a0946&gt;] ? mcast_work_handler+0x1a6/0x710 [ib_sa]
    [&lt;ffffffffa015f01e&gt;] ? ib_send_mad+0xfe/0x3c0 [ib_mad]
    [&lt;ffffffffa00f6c93&gt;] ? ib_get_cached_lmc+0xa3/0xb0 [ib_core]
    [&lt;ffffffffa02a0f9b&gt;] ? join_handler+0xeb/0x200 [ib_sa]
    [&lt;ffffffffa029e4fc&gt;] ? ib_sa_mcmember_rec_callback+0x5c/0xa0 [ib_sa]
    [&lt;ffffffffa029e79c&gt;] ? recv_handler+0x3c/0x70 [ib_sa]
    [&lt;ffffffffa01603a4&gt;] ? ib_mad_completion_handler+0x844/0x9d0 [ib_mad]
    [&lt;ffffffffa015fb60&gt;] ? ib_mad_completion_handler+0x0/0x9d0 [ib_mad]
    [&lt;ffffffff81088830&gt;] ? worker_thread+0x170/0x2a0
    [&lt;ffffffff8108e160&gt;] ? autoremove_wake_function+0x0/0x40
    [&lt;ffffffff810886c0&gt;] ? worker_thread+0x0/0x2a0
    [&lt;ffffffff8108ddf6&gt;] ? kthread+0x96/0xa0
    [&lt;ffffffff8100c1ca&gt;] ? child_rip+0xa/0x20

Coinciding with stack trace is the following message:

    ib0: ib_address_create failed

The code below in ipoib_mcast_join_finish() will note the above
failure in the address handle but otherwise continue:

                ah = ipoib_create_ah(dev, priv-&gt;pd, &amp;av);
                if (!ah) {
                        ipoib_warn(priv, "ib_address_create failed\n");
                } else {

The while loop at the bottom of ipoib_mcast_join_finish() will attempt
to send queued multicast packets in mcast-&gt;pkt_queue and eventually
end up in ipoib_mcast_send():

        if (!mcast-&gt;ah) {
                if (skb_queue_len(&amp;mcast-&gt;pkt_queue) &lt; IPOIB_MAX_MCAST_QUEUE)
                        skb_queue_tail(&amp;mcast-&gt;pkt_queue, skb);
                else {
                        ++dev-&gt;stats.tx_dropped;
                        dev_kfree_skb_any(skb);
                }

My read is that the code will requeue the packet and return to the
ipoib_mcast_join_finish() while loop and the stage is set for the
"hung" task diagnostic as the while loop never sees a non-NULL ah, and
will do nothing to resolve.

There are GFP_ATOMIC allocates in the provider routines, so this is
possible and should be dealt with.

The test that induced the failure is associated with a host SM on the
same server during a shutdown.

This patch causes ipoib_mcast_join_finish() to exit with an error
which will flush the queued mcast packets.  Nothing is done to unwind
the QP attached state so that subsequent sends from above will retry
the join.

Reviewed-by: Ram Vepa &lt;ram.vepa@qlogic.com&gt;
Reviewed-by: Gary Leshner &lt;gary.leshner@qlogic.com&gt;
Signed-off-by: Mike Marciniszyn &lt;mike.marciniszyn@qlogic.com&gt;
Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This following can occur with ipoib when processing a multicast reponse:

    BUG: soft lockup - CPU#0 stuck for 67s! [ib_mad1:982]
    Modules linked in: ...
    CPU 0:
    Modules linked in: ...
    Pid: 982, comm: ib_mad1 Not tainted 2.6.32-131.0.15.el6.x86_64 #1 ProLiant DL160 G5
    RIP: 0010:[&lt;ffffffff814ddb27&gt;]  [&lt;ffffffff814ddb27&gt;] _spin_unlock_irqrestore+0x17/0x20
    RSP: 0018:ffff8802119ed860  EFLAGS: 00000246
    0000000000000004 RBX: ffff8802119ed860 RCX: 000000000000a299
    RDX: ffff88021086c700 RSI: 0000000000000246 RDI: 0000000000000246
    RBP: ffffffff8100bc8e R08: ffff880210ac229c R09: 0000000000000000
    R10: ffff88021278aab8 R11: 0000000000000000 R12: ffff8802119ed860
    R13: ffffffff8100be6e R14: 0000000000000001 R15: 0000000000000003
    FS:  0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    CR2: 00000000006d4840 CR3: 0000000209aa5000 CR4: 00000000000406f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Call Trace:
    [&lt;ffffffffa032c247&gt;] ? ipoib_mcast_send+0x157/0x480 [ib_ipoib]
    [&lt;ffffffff8100bc8e&gt;] ? apic_timer_interrupt+0xe/0x20
    [&lt;ffffffff8100bc8e&gt;] ? apic_timer_interrupt+0xe/0x20
    [&lt;ffffffffa03283d4&gt;] ? ipoib_path_lookup+0x124/0x2d0 [ib_ipoib]
    [&lt;ffffffffa03286fc&gt;] ? ipoib_start_xmit+0x17c/0x430 [ib_ipoib]
    [&lt;ffffffff8141e758&gt;] ? dev_hard_start_xmit+0x2c8/0x3f0
    [&lt;ffffffff81439d0a&gt;] ? sch_direct_xmit+0x15a/0x1c0
    [&lt;ffffffff81423098&gt;] ? dev_queue_xmit+0x388/0x4d0
    [&lt;ffffffffa032d6b7&gt;] ? ipoib_mcast_join_finish+0x2c7/0x510 [ib_ipoib]
    [&lt;ffffffffa032dab8&gt;] ? ipoib_mcast_sendonly_join_complete+0x1b8/0x1f0 [ib_ipoib]
    [&lt;ffffffffa02a0946&gt;] ? mcast_work_handler+0x1a6/0x710 [ib_sa]
    [&lt;ffffffffa015f01e&gt;] ? ib_send_mad+0xfe/0x3c0 [ib_mad]
    [&lt;ffffffffa00f6c93&gt;] ? ib_get_cached_lmc+0xa3/0xb0 [ib_core]
    [&lt;ffffffffa02a0f9b&gt;] ? join_handler+0xeb/0x200 [ib_sa]
    [&lt;ffffffffa029e4fc&gt;] ? ib_sa_mcmember_rec_callback+0x5c/0xa0 [ib_sa]
    [&lt;ffffffffa029e79c&gt;] ? recv_handler+0x3c/0x70 [ib_sa]
    [&lt;ffffffffa01603a4&gt;] ? ib_mad_completion_handler+0x844/0x9d0 [ib_mad]
    [&lt;ffffffffa015fb60&gt;] ? ib_mad_completion_handler+0x0/0x9d0 [ib_mad]
    [&lt;ffffffff81088830&gt;] ? worker_thread+0x170/0x2a0
    [&lt;ffffffff8108e160&gt;] ? autoremove_wake_function+0x0/0x40
    [&lt;ffffffff810886c0&gt;] ? worker_thread+0x0/0x2a0
    [&lt;ffffffff8108ddf6&gt;] ? kthread+0x96/0xa0
    [&lt;ffffffff8100c1ca&gt;] ? child_rip+0xa/0x20

Coinciding with stack trace is the following message:

    ib0: ib_address_create failed

The code below in ipoib_mcast_join_finish() will note the above
failure in the address handle but otherwise continue:

                ah = ipoib_create_ah(dev, priv-&gt;pd, &amp;av);
                if (!ah) {
                        ipoib_warn(priv, "ib_address_create failed\n");
                } else {

The while loop at the bottom of ipoib_mcast_join_finish() will attempt
to send queued multicast packets in mcast-&gt;pkt_queue and eventually
end up in ipoib_mcast_send():

        if (!mcast-&gt;ah) {
                if (skb_queue_len(&amp;mcast-&gt;pkt_queue) &lt; IPOIB_MAX_MCAST_QUEUE)
                        skb_queue_tail(&amp;mcast-&gt;pkt_queue, skb);
                else {
                        ++dev-&gt;stats.tx_dropped;
                        dev_kfree_skb_any(skb);
                }

My read is that the code will requeue the packet and return to the
ipoib_mcast_join_finish() while loop and the stage is set for the
"hung" task diagnostic as the while loop never sees a non-NULL ah, and
will do nothing to resolve.

There are GFP_ATOMIC allocates in the provider routines, so this is
possible and should be dealt with.

The test that induced the failure is associated with a host SM on the
same server during a shutdown.

This patch causes ipoib_mcast_join_finish() to exit with an error
which will flush the queued mcast packets.  Nothing is done to unwind
the QP attached state so that subsequent sends from above will retry
the join.

Reviewed-by: Ram Vepa &lt;ram.vepa@qlogic.com&gt;
Reviewed-by: Gary Leshner &lt;gary.leshner@qlogic.com&gt;
Signed-off-by: Mike Marciniszyn &lt;mike.marciniszyn@qlogic.com&gt;
Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>IB/qib: Fix over-scheduling of QSFP work</title>
<updated>2011-11-28T20:17:33+00:00</updated>
<author>
<name>Mike Marciniszyn</name>
<email>mike.marciniszyn@qlogic.com</email>
</author>
<published>2011-11-09T22:07:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8ee887d74b3d741991edaa1836d22636c28926d9'/>
<id>8ee887d74b3d741991edaa1836d22636c28926d9</id>
<content type='text'>
Don't over-schedule QSFP work on driver initialization.  It could end
up being run simultaneously on two different CPUs resulting in bad
EEPROM reads.  In combination with setting the physical IB link state
prior to the IBC being brought out of reset, this can cause the link
state machine to start training early with wrong settings.

Signed-off-by: Mitko Haralanov &lt;mitko@qlogic.com&gt;
Signed-off-by: Mike Marciniszyn &lt;mike.marciniszyn@qlogic.com&gt;
Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Don't over-schedule QSFP work on driver initialization.  It could end
up being run simultaneously on two different CPUs resulting in bad
EEPROM reads.  In combination with setting the physical IB link state
prior to the IBC being brought out of reset, this can cause the link
state machine to start training early with wrong settings.

Signed-off-by: Mitko Haralanov &lt;mitko@qlogic.com&gt;
Signed-off-by: Mike Marciniszyn &lt;mike.marciniszyn@qlogic.com&gt;
Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>RDMA/cxgb4: Fix retry with MPAv1 logic for MPAv2</title>
<updated>2011-11-28T19:58:07+00:00</updated>
<author>
<name>Kumar Sanghvi</name>
<email>kumaras@chelsio.com</email>
</author>
<published>2011-11-28T16:39:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=01b225e18fcb540c5d615ca79ef832473451f118'/>
<id>01b225e18fcb540c5d615ca79ef832473451f118</id>
<content type='text'>
Fix logic so that we don't retry with MPAv1 once we have done that
already.  Otherwise, we end up retrying with MPAv1 even when its not
needed on getting peer aborts - and this could lead to kernel panic.

Signed-off-by: Kumar Sanghvi &lt;kumaras@chelsio.com&gt;
Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix logic so that we don't retry with MPAv1 once we have done that
already.  Otherwise, we end up retrying with MPAv1 even when its not
needed on getting peer aborts - and this could lead to kernel panic.

Signed-off-by: Kumar Sanghvi &lt;kumaras@chelsio.com&gt;
Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>RDMA/cxgb4: Fix iw_cxgb4 count_rcqes() logic</title>
<updated>2011-11-28T19:53:05+00:00</updated>
<author>
<name>Jonathan Lallinger</name>
<email>jonathan@ogc.us</email>
</author>
<published>2011-10-20T18:25:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c34c97ad8c7c3cdacab2327235c2df4454ff1a06'/>
<id>c34c97ad8c7c3cdacab2327235c2df4454ff1a06</id>
<content type='text'>
Fix another place in the code where logic dealing with the t4_cqe was
using the wrong QID.  This fixes the counting logic so that it tests
against the SQ QID instead of the RQ QID when counting RCQES.

Signed-off by: Jonathan Lallinger &lt;jonathan@ogc.us&gt;
Signed-off by: Steve Wise &lt;swise@ogc.us&gt;
Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix another place in the code where logic dealing with the t4_cqe was
using the wrong QID.  This fixes the counting logic so that it tests
against the SQ QID instead of the RQ QID when counting RCQES.

Signed-off by: Jonathan Lallinger &lt;jonathan@ogc.us&gt;
Signed-off by: Steve Wise &lt;swise@ogc.us&gt;
Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>IB/qib: Don't use schedule_work()</title>
<updated>2011-11-08T18:37:53+00:00</updated>
<author>
<name>Mike Marciniszyn</name>
<email>mike.marciniszyn@qlogic.com</email>
</author>
<published>2011-11-08T18:27:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=042f36e1560cedfe524607791fa44607a3121f63'/>
<id>042f36e1560cedfe524607791fa44607a3121f63</id>
<content type='text'>
It was mistakenly introduced by dde05cbdf8b1 ("IB/qib: Hold links
until tuning data is available").

Signed-off-by: Mike Marciniszyn &lt;mike.marciniszyn@qlogic.com&gt;
Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It was mistakenly introduced by dde05cbdf8b1 ("IB/qib: Hold links
until tuning data is available").

Signed-off-by: Mike Marciniszyn &lt;mike.marciniszyn@qlogic.com&gt;
Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux</title>
<updated>2011-11-07T03:44:47+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2011-11-07T03:44:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=32aaeffbd4a7457bf2f7448b33b5946ff2a960eb'/>
<id>32aaeffbd4a7457bf2f7448b33b5946ff2a960eb</id>
<content type='text'>
* 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: (230 commits)
  Revert "tracing: Include module.h in define_trace.h"
  irq: don't put module.h into irq.h for tracking irqgen modules.
  bluetooth: macroize two small inlines to avoid module.h
  ip_vs.h: fix implicit use of module_get/module_put from module.h
  nf_conntrack.h: fix up fallout from implicit moduleparam.h presence
  include: replace linux/module.h with "struct module" wherever possible
  include: convert various register fcns to macros to avoid include chaining
  crypto.h: remove unused crypto_tfm_alg_modname() inline
  uwb.h: fix implicit use of asm/page.h for PAGE_SIZE
  pm_runtime.h: explicitly requires notifier.h
  linux/dmaengine.h: fix implicit use of bitmap.h and asm/page.h
  miscdevice.h: fix up implicit use of lists and types
  stop_machine.h: fix implicit use of smp.h for smp_processor_id
  of: fix implicit use of errno.h in include/linux/of.h
  of_platform.h: delete needless include &lt;linux/module.h&gt;
  acpi: remove module.h include from platform/aclinux.h
  miscdevice.h: delete unnecessary inclusion of module.h
  device_cgroup.h: delete needless include &lt;linux/module.h&gt;
  net: sch_generic remove redundant use of &lt;linux/module.h&gt;
  net: inet_timewait_sock doesnt need &lt;linux/module.h&gt;
  ...

Fix up trivial conflicts (other header files, and  removal of the ab3550 mfd driver) in
 - drivers/media/dvb/frontends/dibx000_common.c
 - drivers/media/video/{mt9m111.c,ov6650.c}
 - drivers/mfd/ab3550-core.c
 - include/linux/dmaengine.h
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: (230 commits)
  Revert "tracing: Include module.h in define_trace.h"
  irq: don't put module.h into irq.h for tracking irqgen modules.
  bluetooth: macroize two small inlines to avoid module.h
  ip_vs.h: fix implicit use of module_get/module_put from module.h
  nf_conntrack.h: fix up fallout from implicit moduleparam.h presence
  include: replace linux/module.h with "struct module" wherever possible
  include: convert various register fcns to macros to avoid include chaining
  crypto.h: remove unused crypto_tfm_alg_modname() inline
  uwb.h: fix implicit use of asm/page.h for PAGE_SIZE
  pm_runtime.h: explicitly requires notifier.h
  linux/dmaengine.h: fix implicit use of bitmap.h and asm/page.h
  miscdevice.h: fix up implicit use of lists and types
  stop_machine.h: fix implicit use of smp.h for smp_processor_id
  of: fix implicit use of errno.h in include/linux/of.h
  of_platform.h: delete needless include &lt;linux/module.h&gt;
  acpi: remove module.h include from platform/aclinux.h
  miscdevice.h: delete unnecessary inclusion of module.h
  device_cgroup.h: delete needless include &lt;linux/module.h&gt;
  net: sch_generic remove redundant use of &lt;linux/module.h&gt;
  net: inet_timewait_sock doesnt need &lt;linux/module.h&gt;
  ...

Fix up trivial conflicts (other header files, and  removal of the ab3550 mfd driver) in
 - drivers/media/dvb/frontends/dibx000_common.c
 - drivers/media/video/{mt9m111.c,ov6650.c}
 - drivers/mfd/ab3550-core.c
 - include/linux/dmaengine.h
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branches 'iser', 'mthca' and 'qib' into for-next</title>
<updated>2011-11-04T16:36:04+00:00</updated>
<author>
<name>Roland Dreier</name>
<email>roland@purestorage.com</email>
</author>
<published>2011-11-04T16:36:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b8108d6886946cb50434bdbb0214ed81885da8b8'/>
<id>b8108d6886946cb50434bdbb0214ed81885da8b8</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>IB/qib: Fix panic in RC error flushing logic</title>
<updated>2011-11-04T16:35:44+00:00</updated>
<author>
<name>Mike Marciniszyn</name>
<email>mike.marciniszyn@qlogic.com</email>
</author>
<published>2011-11-04T12:26:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=30ab7e230b996f750d4fc24b6bf8214e83effa12'/>
<id>30ab7e230b996f750d4fc24b6bf8214e83effa12</id>
<content type='text'>
The following panic can occur when flushing a QP:

    RIP: 0010:[&lt;ffffffffa0168e8b&gt;]  [&lt;ffffffffa0168e8b&gt;] qib_send_complete+0x3b/0x190 [ib_qib]
    RSP: 0018:ffff8803cdc6fc90  EFLAGS: 00010046
    RAX: 0000000000000000 RBX: ffff8803d84ba000 RCX: 0000000000000000
    RDX: 0000000000000005 RSI: ffffc90015a53430 RDI: ffff8803d84ba000
    RBP: ffff8803cdc6fce0 R08: ffff8803cdc6fc90 R09: 0000000000000001
    R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8803d84ba0c0
    R13: ffff8803d84ba5cc R14: 0000000000000800 R15: 0000000000000246
    FS:  0000000000000000(0000) GS:ffff880036600000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    CR2: 0000000000000034 CR3: 00000003e44f9000 CR4: 00000000000406f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process qib/0 (pid: 1350, threadinfo ffff8803cdc6e000, task ffff88042728a100)
    Stack:
     53544c5553455201 0000000100000005 0000000000000000 ffff8803d84ba000
     0000000000000000 0000000000000000 0000000000000000 0000000000000000
     0000000000000000 0000000000000001 ffff8803cdc6fd30 ffffffffa0165d7a
    Call Trace:
     [&lt;ffffffffa0165d7a&gt;] qib_make_rc_req+0x36a/0xe80 [ib_qib]
     [&lt;ffffffffa0165a10&gt;] ?  qib_make_rc_req+0x0/0xe80 [ib_qib]
     [&lt;ffffffffa01698b3&gt;] qib_do_send+0xf3/0xb60 [ib_qib]
     [&lt;ffffffff814db757&gt;] ? thread_return+0x4e/0x777
     [&lt;ffffffffa01697c0&gt;] ? qib_do_send+0x0/0xb60 [ib_qib]
     [&lt;ffffffff81088bf0&gt;] worker_thread+0x170/0x2a0
     [&lt;ffffffff8108e530&gt;] ?  autoremove_wake_function+0x0/0x40
     [&lt;ffffffff81088a80&gt;] ? worker_thread+0x0/0x2a0
     [&lt;ffffffff8108e1c6&gt;] kthread+0x96/0xa0
     [&lt;ffffffff8100c1ca&gt;] child_rip+0xa/0x20
     [&lt;ffffffff8108e130&gt;] ? kthread+0x0/0xa0
     [&lt;ffffffff8100c1c0&gt;] ? child_rip+0x0/0x20
    RIP  [&lt;ffffffffa0168e8b&gt;] qib_send_complete+0x3b/0x190 [ib_qib]

The RC error state flush logic in qib_make_rc_req() could return all
of the acked wqes and potentially have emptied the queue.  It would
then unconditionally try return a flush completion via
qib_send_complete() for an invalid wqe, or worse a valid one that is
not queued. The panic results when the completion code tries to
maintain an MR reference count for a NULL MR.

This fix modifies logic to only send one completion per
qib_make_rc_req() call and changing the completion status from
IB_WC_SUCCESS to IB_WC_WR_FLUSH_ERR as the completions progress.

The outer loop will call as many times as necessary to flush the queue.

Reviewed-by: Ram Vepa &lt;ram.vepa@qlogic.com&gt;
Signed-off-by: Mike Marciniszyn &lt;mike.marciniszyn@qlogic.com&gt;
Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The following panic can occur when flushing a QP:

    RIP: 0010:[&lt;ffffffffa0168e8b&gt;]  [&lt;ffffffffa0168e8b&gt;] qib_send_complete+0x3b/0x190 [ib_qib]
    RSP: 0018:ffff8803cdc6fc90  EFLAGS: 00010046
    RAX: 0000000000000000 RBX: ffff8803d84ba000 RCX: 0000000000000000
    RDX: 0000000000000005 RSI: ffffc90015a53430 RDI: ffff8803d84ba000
    RBP: ffff8803cdc6fce0 R08: ffff8803cdc6fc90 R09: 0000000000000001
    R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8803d84ba0c0
    R13: ffff8803d84ba5cc R14: 0000000000000800 R15: 0000000000000246
    FS:  0000000000000000(0000) GS:ffff880036600000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    CR2: 0000000000000034 CR3: 00000003e44f9000 CR4: 00000000000406f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process qib/0 (pid: 1350, threadinfo ffff8803cdc6e000, task ffff88042728a100)
    Stack:
     53544c5553455201 0000000100000005 0000000000000000 ffff8803d84ba000
     0000000000000000 0000000000000000 0000000000000000 0000000000000000
     0000000000000000 0000000000000001 ffff8803cdc6fd30 ffffffffa0165d7a
    Call Trace:
     [&lt;ffffffffa0165d7a&gt;] qib_make_rc_req+0x36a/0xe80 [ib_qib]
     [&lt;ffffffffa0165a10&gt;] ?  qib_make_rc_req+0x0/0xe80 [ib_qib]
     [&lt;ffffffffa01698b3&gt;] qib_do_send+0xf3/0xb60 [ib_qib]
     [&lt;ffffffff814db757&gt;] ? thread_return+0x4e/0x777
     [&lt;ffffffffa01697c0&gt;] ? qib_do_send+0x0/0xb60 [ib_qib]
     [&lt;ffffffff81088bf0&gt;] worker_thread+0x170/0x2a0
     [&lt;ffffffff8108e530&gt;] ?  autoremove_wake_function+0x0/0x40
     [&lt;ffffffff81088a80&gt;] ? worker_thread+0x0/0x2a0
     [&lt;ffffffff8108e1c6&gt;] kthread+0x96/0xa0
     [&lt;ffffffff8100c1ca&gt;] child_rip+0xa/0x20
     [&lt;ffffffff8108e130&gt;] ? kthread+0x0/0xa0
     [&lt;ffffffff8100c1c0&gt;] ? child_rip+0x0/0x20
    RIP  [&lt;ffffffffa0168e8b&gt;] qib_send_complete+0x3b/0x190 [ib_qib]

The RC error state flush logic in qib_make_rc_req() could return all
of the acked wqes and potentially have emptied the queue.  It would
then unconditionally try return a flush completion via
qib_send_complete() for an invalid wqe, or worse a valid one that is
not queued. The panic results when the completion code tries to
maintain an MR reference count for a NULL MR.

This fix modifies logic to only send one completion per
qib_make_rc_req() call and changing the completion status from
IB_WC_SUCCESS to IB_WC_WR_FLUSH_ERR as the completions progress.

The outer loop will call as many times as necessary to flush the queue.

Reviewed-by: Ram Vepa &lt;ram.vepa@qlogic.com&gt;
Signed-off-by: Mike Marciniszyn &lt;mike.marciniszyn@qlogic.com&gt;
Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
