<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/infiniband, branch v4.6.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>IB/srp: Fix srp_create_target() error handling</title>
<updated>2016-06-01T19:18:04+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bart.vanassche@sandisk.com</email>
</author>
<published>2016-05-12T17:48:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=80772cfb1c98f38b939a776df6ebcca4e80726a3'/>
<id>80772cfb1c98f38b939a776df6ebcca4e80726a3</id>
<content type='text'>
commit f83b2561a6d4ff12959660ad597580097b744941 upstream.

Avoid that the following kernel oops occurs if memory pool
allocation fails:

BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [&lt;ffffffffa048d0a0&gt;] ib_drain_rq+0x0/0x20 [ib_core]
Call Trace:
 [&lt;ffffffffa04af386&gt;] srp_create_target+0xca6/0x13a9 [ib_srp]
 [&lt;ffffffff813cc863&gt;] dev_attr_store+0x13/0x20
 [&lt;ffffffff81214b50&gt;] sysfs_kf_write+0x40/0x50
 [&lt;ffffffff81213f1c&gt;] kernfs_fop_write+0x13c/0x180
 [&lt;ffffffff81197683&gt;] __vfs_write+0x23/0xf0
 [&lt;ffffffff81198744&gt;] vfs_write+0xa4/0x1a0
 [&lt;ffffffff81199a44&gt;] SyS_write+0x44/0xa0
 [&lt;ffffffff8159e3e9&gt;] entry_SYSCALL_64_fastpath+0x1c/0xac

Fixes: 1dc7b1f10dcb ("IB/srp: use the new CQ API")
Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Reviewed-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Tested-by: Laurence Oberman &lt;loberman@redhat.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f83b2561a6d4ff12959660ad597580097b744941 upstream.

Avoid that the following kernel oops occurs if memory pool
allocation fails:

BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [&lt;ffffffffa048d0a0&gt;] ib_drain_rq+0x0/0x20 [ib_core]
Call Trace:
 [&lt;ffffffffa04af386&gt;] srp_create_target+0xca6/0x13a9 [ib_srp]
 [&lt;ffffffff813cc863&gt;] dev_attr_store+0x13/0x20
 [&lt;ffffffff81214b50&gt;] sysfs_kf_write+0x40/0x50
 [&lt;ffffffff81213f1c&gt;] kernfs_fop_write+0x13c/0x180
 [&lt;ffffffff81197683&gt;] __vfs_write+0x23/0xf0
 [&lt;ffffffff81198744&gt;] vfs_write+0xa4/0x1a0
 [&lt;ffffffff81199a44&gt;] SyS_write+0x44/0xa0
 [&lt;ffffffff8159e3e9&gt;] entry_SYSCALL_64_fastpath+0x1c/0xac

Fixes: 1dc7b1f10dcb ("IB/srp: use the new CQ API")
Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Reviewed-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Tested-by: Laurence Oberman &lt;loberman@redhat.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>IB/srp: Fix a debug kernel crash</title>
<updated>2016-06-01T19:18:04+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bart.vanassche@sandisk.com</email>
</author>
<published>2016-04-12T21:39:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a1e9e0f4f2176938bb1f0bad7d70f9dba27992de'/>
<id>a1e9e0f4f2176938bb1f0bad7d70f9dba27992de</id>
<content type='text'>
commit 54f5c9c52d69afa55abf2b034df8d45f588466c3 upstream.

Avoid that the following BUG() is triggered against a debug
kernel:

kernel BUG at include/linux/scatterlist.h:92!
RIP: 0010:[&lt;ffffffffa0467199&gt;]  [&lt;ffffffffa0467199&gt;] srp_map_idb+0x199/0x1a0 [ib_srp]
Call Trace:
 [&lt;ffffffffa04685fa&gt;] srp_map_data+0x84a/0x890 [ib_srp]
 [&lt;ffffffffa0469674&gt;] srp_queuecommand+0x1e4/0x610 [ib_srp]
 [&lt;ffffffff813f5a5e&gt;] scsi_dispatch_cmd+0x9e/0x180
 [&lt;ffffffff813f8b07&gt;] scsi_request_fn+0x477/0x610
 [&lt;ffffffff81298ffe&gt;] __blk_run_queue+0x2e/0x40
 [&lt;ffffffff81299070&gt;] blk_delay_work+0x20/0x30
 [&lt;ffffffff81071f07&gt;] process_one_work+0x197/0x480
 [&lt;ffffffff81072239&gt;] worker_thread+0x49/0x490
 [&lt;ffffffff810787ea&gt;] kthread+0xea/0x100
 [&lt;ffffffff8159b632&gt;] ret_from_fork+0x22/0x40

Fixes: f7f7aab1a5c0 ("IB/srp: Convert to new registration API")
Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Cc: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Max Gurtovoy &lt;maxg@mellanox.com&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 54f5c9c52d69afa55abf2b034df8d45f588466c3 upstream.

Avoid that the following BUG() is triggered against a debug
kernel:

kernel BUG at include/linux/scatterlist.h:92!
RIP: 0010:[&lt;ffffffffa0467199&gt;]  [&lt;ffffffffa0467199&gt;] srp_map_idb+0x199/0x1a0 [ib_srp]
Call Trace:
 [&lt;ffffffffa04685fa&gt;] srp_map_data+0x84a/0x890 [ib_srp]
 [&lt;ffffffffa0469674&gt;] srp_queuecommand+0x1e4/0x610 [ib_srp]
 [&lt;ffffffff813f5a5e&gt;] scsi_dispatch_cmd+0x9e/0x180
 [&lt;ffffffff813f8b07&gt;] scsi_request_fn+0x477/0x610
 [&lt;ffffffff81298ffe&gt;] __blk_run_queue+0x2e/0x40
 [&lt;ffffffff81299070&gt;] blk_delay_work+0x20/0x30
 [&lt;ffffffff81071f07&gt;] process_one_work+0x197/0x480
 [&lt;ffffffff81072239&gt;] worker_thread+0x49/0x490
 [&lt;ffffffff810787ea&gt;] kthread+0xea/0x100
 [&lt;ffffffff8159b632&gt;] ret_from_fork+0x22/0x40

Fixes: f7f7aab1a5c0 ("IB/srp: Convert to new registration API")
Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Cc: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Max Gurtovoy &lt;maxg@mellanox.com&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma</title>
<updated>2016-05-07T15:10:08+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-05-07T15:10:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b4184cbff393d9ede2d80efd7088126706c1ce08'/>
<id>b4184cbff393d9ede2d80efd7088126706c1ce08</id>
<content type='text'>
Pull rdma fix from Doug Ledford:
 "Fix for max sector calculation in iSER"

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
  IB/iser: Fix max_sectors calculation
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull rdma fix from Doug Ledford:
 "Fix for max sector calculation in iSER"

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
  IB/iser: Fix max_sectors calculation
</pre>
</div>
</content>
</entry>
<entry>
<title>IB/iser: Fix max_sectors calculation</title>
<updated>2016-05-05T16:41:24+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2016-04-18T21:06:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9c674815d346305068b27bf03b5e86b659a1b111'/>
<id>9c674815d346305068b27bf03b5e86b659a1b111</id>
<content type='text'>
iSER currently has a couple places that set max_sectors in either the host
template or SCSI host, and all of them get it wrong.

This patch instead uses a single assignment that (hopefully) gets it right:
the max_sectors value must be derived from the number of segments in the
FR or FMR structure, but actually be one lower than the page size multiplied
by the number of sectors, as it has to handle the case of non-aligned I/O.

Without this I get trivial to reproduce hangs when running xfstests
(on XFS) over iSER to Linux targets.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Max Gurtovoy &lt;maxg@mellanox.com&gt;
Acked-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
iSER currently has a couple places that set max_sectors in either the host
template or SCSI host, and all of them get it wrong.

This patch instead uses a single assignment that (hopefully) gets it right:
the max_sectors value must be derived from the number of segments in the
FR or FMR structure, but actually be one lower than the page size multiplied
by the number of sectors, as it has to handle the case of non-aligned I/O.

Without this I get trivial to reproduce hangs when running xfstests
(on XFS) over iSER to Linux targets.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Max Gurtovoy &lt;maxg@mellanox.com&gt;
Acked-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma</title>
<updated>2016-04-30T00:07:54+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-04-30T00:07:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=925d96a0c9af72e419dbca1db325e09d78f31502'/>
<id>925d96a0c9af72e419dbca1db325e09d78f31502</id>
<content type='text'>
Pull rdma fixes from Doug Ledford:
 "Final set of -rc fixes for 4.6.

  I've collected up a number of patches that are all pretty small with
  the exception of only a couple.  The hfi1 driver has a number of
  important patches, and it is what really drives the line count of this
  pull request up.  These are all small and I've got this kernel built
  and running in the test lab (I have most of the hardware, I think nes
  is the only thing in this patch set that I can't say I've personally
  tested and have up and running).

  Summary:

   - A number of collected fixes for oopses, memory corruptions,
     deadlocks, etc.  All of these fixes are small (many only 5-10
     lines), obvious, and tested.

   - Fix for the security issue related to the use of write for
     bi-directional communications"

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
  RDMA/nes: don't leak skb if carrier down
  IB/security: Restrict use of the write() interface
  IB/hfi1: Use kernel default llseek for ui device
  IB/hfi1: Don't attempt to free resources if initialization failed
  IB/hfi1: Fix missing lock/unlock in verbs drain callback
  IB/rdmavt: Fix send scheduling
  IB/hfi1: Prevent unpinning of wrong pages
  IB/hfi1: Fix deadlock caused by locking with wrong scope
  IB/hfi1: Prevent NULL pointer deferences in caching code
  MAINTAINERS: Update iser/isert maintainer contact info
  IB/mlx5: Expose correct max_sge_rd limit
  RDMA/iw_cxgb4: Fix bar2 virt addr calculation for T4 chips
  iw_cxgb4: handle draining an idle qp
  iw_cxgb3: initialize ibdev.iwcm-&gt;ifname for port mapping
  iw_cxgb4: initialize ibdev.iwcm-&gt;ifname for port mapping
  IB/core: Don't drain non-existent rq queue-pair
  IB/core: Fix oops in ib_cache_gid_set_default_gid
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull rdma fixes from Doug Ledford:
 "Final set of -rc fixes for 4.6.

  I've collected up a number of patches that are all pretty small with
  the exception of only a couple.  The hfi1 driver has a number of
  important patches, and it is what really drives the line count of this
  pull request up.  These are all small and I've got this kernel built
  and running in the test lab (I have most of the hardware, I think nes
  is the only thing in this patch set that I can't say I've personally
  tested and have up and running).

  Summary:

   - A number of collected fixes for oopses, memory corruptions,
     deadlocks, etc.  All of these fixes are small (many only 5-10
     lines), obvious, and tested.

   - Fix for the security issue related to the use of write for
     bi-directional communications"

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
  RDMA/nes: don't leak skb if carrier down
  IB/security: Restrict use of the write() interface
  IB/hfi1: Use kernel default llseek for ui device
  IB/hfi1: Don't attempt to free resources if initialization failed
  IB/hfi1: Fix missing lock/unlock in verbs drain callback
  IB/rdmavt: Fix send scheduling
  IB/hfi1: Prevent unpinning of wrong pages
  IB/hfi1: Fix deadlock caused by locking with wrong scope
  IB/hfi1: Prevent NULL pointer deferences in caching code
  MAINTAINERS: Update iser/isert maintainer contact info
  IB/mlx5: Expose correct max_sge_rd limit
  RDMA/iw_cxgb4: Fix bar2 virt addr calculation for T4 chips
  iw_cxgb4: handle draining an idle qp
  iw_cxgb3: initialize ibdev.iwcm-&gt;ifname for port mapping
  iw_cxgb4: initialize ibdev.iwcm-&gt;ifname for port mapping
  IB/core: Don't drain non-existent rq queue-pair
  IB/core: Fix oops in ib_cache_gid_set_default_gid
</pre>
</div>
</content>
</entry>
<entry>
<title>RDMA/nes: don't leak skb if carrier down</title>
<updated>2016-04-29T01:11:09+00:00</updated>
<author>
<name>Florian Westphal</name>
<email>fw@strlen.de</email>
</author>
<published>2016-04-24T20:18:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4c8bb95921e9ac01b9dd0c3abbaf6514ce88af92'/>
<id>4c8bb95921e9ac01b9dd0c3abbaf6514ce88af92</id>
<content type='text'>
Alternatively one could free the skb, OTOH I don't think this test is
useful so just remove it.

Cc: &lt;linux-rdma@vger.kernel.org&gt;
Signed-off-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Alternatively one could free the skb, OTOH I don't think this test is
useful so just remove it.

Cc: &lt;linux-rdma@vger.kernel.org&gt;
Signed-off-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>IB/security: Restrict use of the write() interface</title>
<updated>2016-04-28T16:03:16+00:00</updated>
<author>
<name>Jason Gunthorpe</name>
<email>jgunthorpe@obsidianresearch.com</email>
</author>
<published>2016-04-11T01:13:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3'/>
<id>e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3</id>
<content type='text'>
The drivers/infiniband stack uses write() as a replacement for
bi-directional ioctl().  This is not safe. There are ways to
trigger write calls that result in the return structure that
is normally written to user space being shunted off to user
specified kernel memory instead.

For the immediate repair, detect and deny suspicious accesses to
the write API.

For long term, update the user space libraries and the kernel API
to something that doesn't present the same security vulnerabilities
(likely a structured ioctl() interface).

The impacted uAPI interfaces are generally only available if
hardware from drivers/infiniband is installed in the system.

Reported-by: Jann Horn &lt;jann@thejh.net&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
[ Expanded check to all known write() entry points ]
Cc: stable@vger.kernel.org
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The drivers/infiniband stack uses write() as a replacement for
bi-directional ioctl().  This is not safe. There are ways to
trigger write calls that result in the return structure that
is normally written to user space being shunted off to user
specified kernel memory instead.

For the immediate repair, detect and deny suspicious accesses to
the write API.

For long term, update the user space libraries and the kernel API
to something that doesn't present the same security vulnerabilities
(likely a structured ioctl() interface).

The impacted uAPI interfaces are generally only available if
hardware from drivers/infiniband is installed in the system.

Reported-by: Jann Horn &lt;jann@thejh.net&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
[ Expanded check to all known write() entry points ]
Cc: stable@vger.kernel.org
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>IB/rdmavt: Fix send scheduling</title>
<updated>2016-04-28T16:00:39+00:00</updated>
<author>
<name>Jubin John</name>
<email>jubin.john@intel.com</email>
</author>
<published>2016-04-12T17:47:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e6d2e0176e1f3c1e1534851b66c0b972f03ff069'/>
<id>e6d2e0176e1f3c1e1534851b66c0b972f03ff069</id>
<content type='text'>
call_send is used to determine whether to send immediately or schedule
a send for later. The current logic in rdmavt is inverted and has a
negative impact on the latency of the hfi1 and qib drivers. Fix this
regression by correctly calling send immediately when call_send is set.

Reviewed-by: Dennis Dalessandro &lt;dennis.dalessandro@intel.com&gt;
Reviewed-by: Mike Marciniszyn &lt;mike.marciniszyn@intel.com&gt;
Signed-off-by: Jubin John &lt;jubin.john@intel.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
call_send is used to determine whether to send immediately or schedule
a send for later. The current logic in rdmavt is inverted and has a
negative impact on the latency of the hfi1 and qib drivers. Fix this
regression by correctly calling send immediately when call_send is set.

Reviewed-by: Dennis Dalessandro &lt;dennis.dalessandro@intel.com&gt;
Reviewed-by: Mike Marciniszyn &lt;mike.marciniszyn@intel.com&gt;
Signed-off-by: Jubin John &lt;jubin.john@intel.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>IB/mlx5: Expose correct max_sge_rd limit</title>
<updated>2016-04-28T14:49:17+00:00</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagi@grimberg.me</email>
</author>
<published>2016-03-31T16:03:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=986ef95ecdd3eb6fa29433e68faa94c7624083be'/>
<id>986ef95ecdd3eb6fa29433e68faa94c7624083be</id>
<content type='text'>
mlx5 devices (Connect-IB, ConnectX-4, ConnectX-4-LX) has a limitation
where rdma read work queue entries cannot exceed 512 bytes.
A rdma_read wqe needs to fit in 512 bytes:
- wqe control segment (16 bytes)
- rdma segment (16 bytes)
- scatter elements (16 bytes each)

So max_sge_rd should be: (512 - 16 - 16) / 16 = 30.

Cc: linux-stable@vger.kernel.org
Reported-by: Christoph Hellwig &lt;hch@lst.de&gt;
Tested-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sagi Grimberg &lt;sagig@grimberg.me&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
mlx5 devices (Connect-IB, ConnectX-4, ConnectX-4-LX) has a limitation
where rdma read work queue entries cannot exceed 512 bytes.
A rdma_read wqe needs to fit in 512 bytes:
- wqe control segment (16 bytes)
- rdma segment (16 bytes)
- scatter elements (16 bytes each)

So max_sge_rd should be: (512 - 16 - 16) / 16 = 30.

Cc: linux-stable@vger.kernel.org
Reported-by: Christoph Hellwig &lt;hch@lst.de&gt;
Tested-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sagi Grimberg &lt;sagig@grimberg.me&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>RDMA/iw_cxgb4: Fix bar2 virt addr calculation for T4 chips</title>
<updated>2016-04-26T16:47:09+00:00</updated>
<author>
<name>Hariprasad S</name>
<email>hariprasad@chelsio.com</email>
</author>
<published>2016-04-05T04:53:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=32cc92c7b5e52357a0a24010bae9eb257fa75d3e'/>
<id>32cc92c7b5e52357a0a24010bae9eb257fa75d3e</id>
<content type='text'>
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

  &lt;1&gt;BUG: unable to handle kernel paging request at 000000000002aa08
  &lt;1&gt;IP: [&lt;ffffffffa011d800&gt;] c4iw_uld_control+0x4e0/0x880 [iw_cxgb4]
  &lt;4&gt;PGD 1416a8067 PUD 15bf35067 PMD 0
  &lt;4&gt;Oops: 0002 [#1] SMP
  &lt;4&gt;last sysfs file:
  /sys/devices/pci0000:00/0000:00:03.0/0000:02:00.4/infiniband/cxgb4_0/node_guid
  &lt;4&gt;CPU 5
  &lt;4&gt;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]
  &lt;4&gt;
  Supermicro X8ST3/X8ST3
  &lt;4&gt;RIP: 0010:[&lt;ffffffffa011d800&gt;]  [&lt;ffffffffa011d800&gt;]
  c4iw_uld_control+0x4e0/0x880 [iw_cxgb4]
  &lt;4&gt;RSP: 0000:ffff880155a03db0  EFLAGS: 00010006
  &lt;4&gt;RAX: 000000000000001d RBX: ffff88013ae5fc00 RCX: ffff880155adb180
  &lt;4&gt;RDX: 000000000002aa00 RSI: 0000000000000001 RDI: ffff88013ae5fdf8
  &lt;4&gt;RBP: ffff880155a03e10 R08: 0000000000000000 R09: 0000000000000001
  &lt;4&gt;R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
  &lt;4&gt;R13: 000000000000001d R14: ffff880156414ab0 R15: ffffe8ffffc05b88
  &lt;4&gt;FS:  0000000000000000(0000) GS:ffff8800282a0000(0000) knlGS:0000000000000000
  &lt;4&gt;CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
  &lt;4&gt;CR2: 000000000002aa08 CR3: 000000015bd0e000 CR4: 00000000000007e0
  &lt;4&gt;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  &lt;4&gt;DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  &lt;4&gt;Process cxgb4 (pid: 394, threadinfo ffff880155a00000, task ffff880156414ab0)
  &lt;4&gt;Stack:
  &lt;4&gt; ffff880156415068 ffff880155adb180 ffff880155a03df0 ffffffffa00a344b
  &lt;4&gt;&lt;d&gt; 00000000000003e8 ffff880155920000 0000000000000004 ffff880155920000
  &lt;4&gt;&lt;d&gt; ffff88015592d438 ffffffffa00a3860 ffff880155a03fd8 ffffe8ffffc05b88
  &lt;4&gt;Call Trace:
  &lt;4&gt; [&lt;ffffffffa00a344b&gt;] ? enable_txq_db+0x2b/0x80 [cxgb4]
  &lt;4&gt; [&lt;ffffffffa00a3860&gt;] ? process_db_full+0x0/0xa0 [cxgb4]
  &lt;4&gt; [&lt;ffffffffa00a38a6&gt;] process_db_full+0x46/0xa0 [cxgb4]
  &lt;4&gt; [&lt;ffffffff8109fda0&gt;] worker_thread+0x170/0x2a0
  &lt;4&gt; [&lt;ffffffff810a6aa0&gt;] ? autoremove_wake_function+0x0/0x40
  &lt;4&gt; [&lt;ffffffff8109fc30&gt;] ? worker_thread+0x0/0x2a0
  &lt;4&gt; [&lt;ffffffff810a660e&gt;] kthread+0x9e/0xc0
  &lt;4&gt; [&lt;ffffffff8100c28a&gt;] child_rip+0xa/0x20
  &lt;4&gt; [&lt;ffffffff810a6570&gt;] ? kthread+0x0/0xc0
  &lt;4&gt; [&lt;ffffffff8100c280&gt;] ? child_rip+0x0/0x20
  &lt;4&gt;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 &lt;89&gt; 42 08 0f ae f8
  66 c7 83 82 01 00 00 00 00 44 0f b7 ab dc 01
  &lt;1&gt;RIP  [&lt;ffffffffa011d800&gt;] c4iw_uld_control+0x4e0/0x880 [iw_cxgb4]
  &lt;4&gt; RSP &lt;ffff880155a03db0&gt;
  &lt;4&gt;CR2: 000000000002aa08`

Based on original work by Bharat Potnuri &lt;bharat@chelsio.com&gt;

Fixes: 74217d4c6a4fb0d8 ("iw_cxgb4: support for bar2 qid densities exceeding the page size")

Signed-off-by: Steve Wise &lt;swise@opengridcomputing.com&gt;
Signed-off-by: Hariprasad Shenai &lt;hariprasad@chelsio.com&gt;
Reviewed-by: Leon Romanovsky &lt;leon@leon.nu&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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

  &lt;1&gt;BUG: unable to handle kernel paging request at 000000000002aa08
  &lt;1&gt;IP: [&lt;ffffffffa011d800&gt;] c4iw_uld_control+0x4e0/0x880 [iw_cxgb4]
  &lt;4&gt;PGD 1416a8067 PUD 15bf35067 PMD 0
  &lt;4&gt;Oops: 0002 [#1] SMP
  &lt;4&gt;last sysfs file:
  /sys/devices/pci0000:00/0000:00:03.0/0000:02:00.4/infiniband/cxgb4_0/node_guid
  &lt;4&gt;CPU 5
  &lt;4&gt;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]
  &lt;4&gt;
  Supermicro X8ST3/X8ST3
  &lt;4&gt;RIP: 0010:[&lt;ffffffffa011d800&gt;]  [&lt;ffffffffa011d800&gt;]
  c4iw_uld_control+0x4e0/0x880 [iw_cxgb4]
  &lt;4&gt;RSP: 0000:ffff880155a03db0  EFLAGS: 00010006
  &lt;4&gt;RAX: 000000000000001d RBX: ffff88013ae5fc00 RCX: ffff880155adb180
  &lt;4&gt;RDX: 000000000002aa00 RSI: 0000000000000001 RDI: ffff88013ae5fdf8
  &lt;4&gt;RBP: ffff880155a03e10 R08: 0000000000000000 R09: 0000000000000001
  &lt;4&gt;R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
  &lt;4&gt;R13: 000000000000001d R14: ffff880156414ab0 R15: ffffe8ffffc05b88
  &lt;4&gt;FS:  0000000000000000(0000) GS:ffff8800282a0000(0000) knlGS:0000000000000000
  &lt;4&gt;CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
  &lt;4&gt;CR2: 000000000002aa08 CR3: 000000015bd0e000 CR4: 00000000000007e0
  &lt;4&gt;DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  &lt;4&gt;DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  &lt;4&gt;Process cxgb4 (pid: 394, threadinfo ffff880155a00000, task ffff880156414ab0)
  &lt;4&gt;Stack:
  &lt;4&gt; ffff880156415068 ffff880155adb180 ffff880155a03df0 ffffffffa00a344b
  &lt;4&gt;&lt;d&gt; 00000000000003e8 ffff880155920000 0000000000000004 ffff880155920000
  &lt;4&gt;&lt;d&gt; ffff88015592d438 ffffffffa00a3860 ffff880155a03fd8 ffffe8ffffc05b88
  &lt;4&gt;Call Trace:
  &lt;4&gt; [&lt;ffffffffa00a344b&gt;] ? enable_txq_db+0x2b/0x80 [cxgb4]
  &lt;4&gt; [&lt;ffffffffa00a3860&gt;] ? process_db_full+0x0/0xa0 [cxgb4]
  &lt;4&gt; [&lt;ffffffffa00a38a6&gt;] process_db_full+0x46/0xa0 [cxgb4]
  &lt;4&gt; [&lt;ffffffff8109fda0&gt;] worker_thread+0x170/0x2a0
  &lt;4&gt; [&lt;ffffffff810a6aa0&gt;] ? autoremove_wake_function+0x0/0x40
  &lt;4&gt; [&lt;ffffffff8109fc30&gt;] ? worker_thread+0x0/0x2a0
  &lt;4&gt; [&lt;ffffffff810a660e&gt;] kthread+0x9e/0xc0
  &lt;4&gt; [&lt;ffffffff8100c28a&gt;] child_rip+0xa/0x20
  &lt;4&gt; [&lt;ffffffff810a6570&gt;] ? kthread+0x0/0xc0
  &lt;4&gt; [&lt;ffffffff8100c280&gt;] ? child_rip+0x0/0x20
  &lt;4&gt;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 &lt;89&gt; 42 08 0f ae f8
  66 c7 83 82 01 00 00 00 00 44 0f b7 ab dc 01
  &lt;1&gt;RIP  [&lt;ffffffffa011d800&gt;] c4iw_uld_control+0x4e0/0x880 [iw_cxgb4]
  &lt;4&gt; RSP &lt;ffff880155a03db0&gt;
  &lt;4&gt;CR2: 000000000002aa08`

Based on original work by Bharat Potnuri &lt;bharat@chelsio.com&gt;

Fixes: 74217d4c6a4fb0d8 ("iw_cxgb4: support for bar2 qid densities exceeding the page size")

Signed-off-by: Steve Wise &lt;swise@opengridcomputing.com&gt;
Signed-off-by: Hariprasad Shenai &lt;hariprasad@chelsio.com&gt;
Reviewed-by: Leon Romanovsky &lt;leon@leon.nu&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
