<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/block/nbd.c, branch v5.4</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>nbd:fix memory leak in nbd_get_socket()</title>
<updated>2019-11-19T16:23:26+00:00</updated>
<author>
<name>Sun Ke</name>
<email>sunke32@huawei.com</email>
</author>
<published>2019-11-19T06:09:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dff10bbea4be47bdb615b036c834a275b7c68133'/>
<id>dff10bbea4be47bdb615b036c834a275b7c68133</id>
<content type='text'>
Before returning NULL, put the sock first.

Cc: stable@vger.kernel.org
Fixes: cf1b2326b734 ("nbd: verify socket is supported during setup")
Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Reviewed-by: Mike Christie &lt;mchristi@redhat.com&gt;
Signed-off-by: Sun Ke &lt;sunke32@huawei.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Before returning NULL, put the sock first.

Cc: stable@vger.kernel.org
Fixes: cf1b2326b734 ("nbd: verify socket is supported during setup")
Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Reviewed-by: Mike Christie &lt;mchristi@redhat.com&gt;
Signed-off-by: Sun Ke &lt;sunke32@huawei.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nbd: verify socket is supported during setup</title>
<updated>2019-10-25T20:37:21+00:00</updated>
<author>
<name>Mike Christie</name>
<email>mchristi@redhat.com</email>
</author>
<published>2019-10-17T21:27:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cf1b2326b734896734c6e167e41766f9cee7686a'/>
<id>cf1b2326b734896734c6e167e41766f9cee7686a</id>
<content type='text'>
nbd requires socket families to support the shutdown method so the nbd
recv workqueue can be woken up from its sock_recvmsg call. If the socket
does not support the callout we will leave recv works running or get hangs
later when the device or module is removed.

This adds a check during socket connection/reconnection to make sure the
socket being passed in supports the needed callout.

Reported-by: syzbot+24c12fa8d218ed26011a@syzkaller.appspotmail.com
Fixes: e9e006f5fcf2 ("nbd: fix max number of supported devs")
Tested-by: Richard W.M. Jones &lt;rjones@redhat.com&gt;
Signed-off-by: Mike Christie &lt;mchristi@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
nbd requires socket families to support the shutdown method so the nbd
recv workqueue can be woken up from its sock_recvmsg call. If the socket
does not support the callout we will leave recv works running or get hangs
later when the device or module is removed.

This adds a check during socket connection/reconnection to make sure the
socket being passed in supports the needed callout.

Reported-by: syzbot+24c12fa8d218ed26011a@syzkaller.appspotmail.com
Fixes: e9e006f5fcf2 ("nbd: fix max number of supported devs")
Tested-by: Richard W.M. Jones &lt;rjones@redhat.com&gt;
Signed-off-by: Mike Christie &lt;mchristi@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nbd: handle racing with error'ed out commands</title>
<updated>2019-10-25T20:20:03+00:00</updated>
<author>
<name>Josef Bacik</name>
<email>josef@toxicpanda.com</email>
</author>
<published>2019-10-21T19:56:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7ce23e8e0a9cd38338fc8316ac5772666b565ca9'/>
<id>7ce23e8e0a9cd38338fc8316ac5772666b565ca9</id>
<content type='text'>
We hit the following warning in production

print_req_error: I/O error, dev nbd0, sector 7213934408 flags 80700
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 25 PID: 32407 at lib/refcount.c:190 refcount_sub_and_test_checked+0x53/0x60
Workqueue: knbd-recv recv_work [nbd]
RIP: 0010:refcount_sub_and_test_checked+0x53/0x60
Call Trace:
 blk_mq_free_request+0xb7/0xf0
 blk_mq_complete_request+0x62/0xf0
 recv_work+0x29/0xa1 [nbd]
 process_one_work+0x1f5/0x3f0
 worker_thread+0x2d/0x3d0
 ? rescuer_thread+0x340/0x340
 kthread+0x111/0x130
 ? kthread_create_on_node+0x60/0x60
 ret_from_fork+0x1f/0x30
---[ end trace b079c3c67f98bb7c ]---

This was preceded by us timing out everything and shutting down the
sockets for the device.  The problem is we had a request in the queue at
the same time, so we completed the request twice.  This can actually
happen in a lot of cases, we fail to get a ref on our config, we only
have one connection and just error out the command, etc.

Fix this by checking cmd-&gt;status in nbd_read_stat.  We only change this
under the cmd-&gt;lock, so we are safe to check this here and see if we've
already error'ed this command out, which would indicate that we've
completed it as well.

Reviewed-by: Mike Christie &lt;mchristi@redhat.com&gt;
Signed-off-by: Josef Bacik &lt;josef@toxicpanda.com&gt;

Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We hit the following warning in production

print_req_error: I/O error, dev nbd0, sector 7213934408 flags 80700
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 25 PID: 32407 at lib/refcount.c:190 refcount_sub_and_test_checked+0x53/0x60
Workqueue: knbd-recv recv_work [nbd]
RIP: 0010:refcount_sub_and_test_checked+0x53/0x60
Call Trace:
 blk_mq_free_request+0xb7/0xf0
 blk_mq_complete_request+0x62/0xf0
 recv_work+0x29/0xa1 [nbd]
 process_one_work+0x1f5/0x3f0
 worker_thread+0x2d/0x3d0
 ? rescuer_thread+0x340/0x340
 kthread+0x111/0x130
 ? kthread_create_on_node+0x60/0x60
 ret_from_fork+0x1f/0x30
---[ end trace b079c3c67f98bb7c ]---

This was preceded by us timing out everything and shutting down the
sockets for the device.  The problem is we had a request in the queue at
the same time, so we completed the request twice.  This can actually
happen in a lot of cases, we fail to get a ref on our config, we only
have one connection and just error out the command, etc.

Fix this by checking cmd-&gt;status in nbd_read_stat.  We only change this
under the cmd-&gt;lock, so we are safe to check this here and see if we've
already error'ed this command out, which would indicate that we've
completed it as well.

Reviewed-by: Mike Christie &lt;mchristi@redhat.com&gt;
Signed-off-by: Josef Bacik &lt;josef@toxicpanda.com&gt;

Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nbd: protect cmd-&gt;status with cmd-&gt;lock</title>
<updated>2019-10-25T20:20:01+00:00</updated>
<author>
<name>Josef Bacik</name>
<email>josef@toxicpanda.com</email>
</author>
<published>2019-10-21T19:56:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=de6346ecbc8f5591ebd6c44ac164e8b8671d71d7'/>
<id>de6346ecbc8f5591ebd6c44ac164e8b8671d71d7</id>
<content type='text'>
We already do this for the most part, except in timeout and clear_req.
For the timeout case we take the lock after we grab a ref on the config,
but that isn't really necessary because we're safe to touch the cmd at
this point, so just move the order around.

For the clear_req cause this is initiated by the user, so again is safe.

Reviewed-by: Mike Christie &lt;mchristi@redhat.com&gt;
Signed-off-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We already do this for the most part, except in timeout and clear_req.
For the timeout case we take the lock after we grab a ref on the config,
but that isn't really necessary because we're safe to touch the cmd at
this point, so just move the order around.

For the clear_req cause this is initiated by the user, so again is safe.

Reviewed-by: Mike Christie &lt;mchristi@redhat.com&gt;
Signed-off-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nbd: fix possible sysfs duplicate warning</title>
<updated>2019-10-10T15:44:56+00:00</updated>
<author>
<name>Xiubo Li</name>
<email>xiubli@redhat.com</email>
</author>
<published>2019-09-19T06:14:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=862488105b84ca744b3d8ff131e0fcfe10644be1'/>
<id>862488105b84ca744b3d8ff131e0fcfe10644be1</id>
<content type='text'>
1. nbd_put takes the mutex and drops nbd-&gt;ref to 0. It then does
idr_remove and drops the mutex.

2. nbd_genl_connect takes the mutex. idr_find/idr_for_each fails
to find an existing device, so it does nbd_dev_add.

3. just before the nbd_put could call nbd_dev_remove or not finished
totally, but if nbd_dev_add try to add_disk, we can hit:

debugfs: Directory 'nbd1' with parent 'block' already present!

This patch will make sure all the disk add/remove stuff are done
by holding the nbd_index_mutex lock.

Reported-by: Mike Christie &lt;mchristi@redhat.com&gt;
Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Signed-off-by: Xiubo Li &lt;xiubli@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
1. nbd_put takes the mutex and drops nbd-&gt;ref to 0. It then does
idr_remove and drops the mutex.

2. nbd_genl_connect takes the mutex. idr_find/idr_for_each fails
to find an existing device, so it does nbd_dev_add.

3. just before the nbd_put could call nbd_dev_remove or not finished
totally, but if nbd_dev_add try to add_disk, we can hit:

debugfs: Directory 'nbd1' with parent 'block' already present!

This patch will make sure all the disk add/remove stuff are done
by holding the nbd_index_mutex lock.

Reported-by: Mike Christie &lt;mchristi@redhat.com&gt;
Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Signed-off-by: Xiubo Li &lt;xiubli@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nbd: fix possible page fault for nbd disk</title>
<updated>2019-09-18T02:03:49+00:00</updated>
<author>
<name>Xiubo Li</name>
<email>xiubli@redhat.com</email>
</author>
<published>2019-09-17T11:56:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8454d68563d400fa09b63dc636361b6702ceb8af'/>
<id>8454d68563d400fa09b63dc636361b6702ceb8af</id>
<content type='text'>
When the NBD_CFLAG_DESTROY_ON_DISCONNECT flag is set and at the same
time when the socket is closed due to the server daemon is restarted,
just before the last DISCONNET is totally done if we start a new connection
by using the old nbd_index, there will be crashing randomly, like:

&lt;3&gt;[  110.151949] block nbd1: Receive control failed (result -32)
&lt;1&gt;[  110.152024] BUG: unable to handle page fault for address: 0000058000000840
&lt;1&gt;[  110.152063] #PF: supervisor read access in kernel mode
&lt;1&gt;[  110.152083] #PF: error_code(0x0000) - not-present page
&lt;6&gt;[  110.152094] PGD 0 P4D 0
&lt;4&gt;[  110.152106] Oops: 0000 [#1] SMP PTI
&lt;4&gt;[  110.152120] CPU: 0 PID: 6698 Comm: kworker/u5:1 Kdump: loaded Not tainted 5.3.0-rc4+ #2
&lt;4&gt;[  110.152136] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
&lt;4&gt;[  110.152166] Workqueue: knbd-recv recv_work [nbd]
&lt;4&gt;[  110.152187] RIP: 0010:__dev_printk+0xd/0x67
&lt;4&gt;[  110.152206] Code: 10 e8 c5 fd ff ff 48 8b 4c 24 18 65 48 33 0c 25 28 00 [...]
&lt;4&gt;[  110.152244] RSP: 0018:ffffa41581f13d18 EFLAGS: 00010206
&lt;4&gt;[  110.152256] RAX: ffffa41581f13d30 RBX: ffff96dd7374e900 RCX: 0000000000000000
&lt;4&gt;[  110.152271] RDX: ffffa41581f13d20 RSI: 00000580000007f0 RDI: ffffffff970ec24f
&lt;4&gt;[  110.152285] RBP: ffffa41581f13d80 R08: ffff96dd7fc17908 R09: 0000000000002e56
&lt;4&gt;[  110.152299] R10: ffffffff970ec24f R11: 0000000000000003 R12: ffff96dd7374e900
&lt;4&gt;[  110.152313] R13: 0000000000000000 R14: ffff96dd7374e9d8 R15: ffff96dd6e3b02c8
&lt;4&gt;[  110.152329] FS:  0000000000000000(0000) GS:ffff96dd7fc00000(0000) knlGS:0000000000000000
&lt;4&gt;[  110.152362] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
&lt;4&gt;[  110.152383] CR2: 0000058000000840 CR3: 0000000067cc6002 CR4: 00000000001606f0
&lt;4&gt;[  110.152401] Call Trace:
&lt;4&gt;[  110.152422]  _dev_err+0x6c/0x83
&lt;4&gt;[  110.152435]  nbd_read_stat.cold+0xda/0x578 [nbd]
&lt;4&gt;[  110.152448]  ? __switch_to_asm+0x34/0x70
&lt;4&gt;[  110.152468]  ? __switch_to_asm+0x40/0x70
&lt;4&gt;[  110.152478]  ? __switch_to_asm+0x34/0x70
&lt;4&gt;[  110.152491]  ? __switch_to_asm+0x40/0x70
&lt;4&gt;[  110.152501]  ? __switch_to_asm+0x34/0x70
&lt;4&gt;[  110.152511]  ? __switch_to_asm+0x40/0x70
&lt;4&gt;[  110.152522]  ? __switch_to_asm+0x34/0x70
&lt;4&gt;[  110.152533]  recv_work+0x35/0x9e [nbd]
&lt;4&gt;[  110.152547]  process_one_work+0x19d/0x340
&lt;4&gt;[  110.152558]  worker_thread+0x50/0x3b0
&lt;4&gt;[  110.152568]  kthread+0xfb/0x130
&lt;4&gt;[  110.152577]  ? process_one_work+0x340/0x340
&lt;4&gt;[  110.152609]  ? kthread_park+0x80/0x80
&lt;4&gt;[  110.152637]  ret_from_fork+0x35/0x40

This is very easy to reproduce by running the nbd-runner.

Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Signed-off-by: Xiubo Li &lt;xiubli@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When the NBD_CFLAG_DESTROY_ON_DISCONNECT flag is set and at the same
time when the socket is closed due to the server daemon is restarted,
just before the last DISCONNET is totally done if we start a new connection
by using the old nbd_index, there will be crashing randomly, like:

&lt;3&gt;[  110.151949] block nbd1: Receive control failed (result -32)
&lt;1&gt;[  110.152024] BUG: unable to handle page fault for address: 0000058000000840
&lt;1&gt;[  110.152063] #PF: supervisor read access in kernel mode
&lt;1&gt;[  110.152083] #PF: error_code(0x0000) - not-present page
&lt;6&gt;[  110.152094] PGD 0 P4D 0
&lt;4&gt;[  110.152106] Oops: 0000 [#1] SMP PTI
&lt;4&gt;[  110.152120] CPU: 0 PID: 6698 Comm: kworker/u5:1 Kdump: loaded Not tainted 5.3.0-rc4+ #2
&lt;4&gt;[  110.152136] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
&lt;4&gt;[  110.152166] Workqueue: knbd-recv recv_work [nbd]
&lt;4&gt;[  110.152187] RIP: 0010:__dev_printk+0xd/0x67
&lt;4&gt;[  110.152206] Code: 10 e8 c5 fd ff ff 48 8b 4c 24 18 65 48 33 0c 25 28 00 [...]
&lt;4&gt;[  110.152244] RSP: 0018:ffffa41581f13d18 EFLAGS: 00010206
&lt;4&gt;[  110.152256] RAX: ffffa41581f13d30 RBX: ffff96dd7374e900 RCX: 0000000000000000
&lt;4&gt;[  110.152271] RDX: ffffa41581f13d20 RSI: 00000580000007f0 RDI: ffffffff970ec24f
&lt;4&gt;[  110.152285] RBP: ffffa41581f13d80 R08: ffff96dd7fc17908 R09: 0000000000002e56
&lt;4&gt;[  110.152299] R10: ffffffff970ec24f R11: 0000000000000003 R12: ffff96dd7374e900
&lt;4&gt;[  110.152313] R13: 0000000000000000 R14: ffff96dd7374e9d8 R15: ffff96dd6e3b02c8
&lt;4&gt;[  110.152329] FS:  0000000000000000(0000) GS:ffff96dd7fc00000(0000) knlGS:0000000000000000
&lt;4&gt;[  110.152362] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
&lt;4&gt;[  110.152383] CR2: 0000058000000840 CR3: 0000000067cc6002 CR4: 00000000001606f0
&lt;4&gt;[  110.152401] Call Trace:
&lt;4&gt;[  110.152422]  _dev_err+0x6c/0x83
&lt;4&gt;[  110.152435]  nbd_read_stat.cold+0xda/0x578 [nbd]
&lt;4&gt;[  110.152448]  ? __switch_to_asm+0x34/0x70
&lt;4&gt;[  110.152468]  ? __switch_to_asm+0x40/0x70
&lt;4&gt;[  110.152478]  ? __switch_to_asm+0x34/0x70
&lt;4&gt;[  110.152491]  ? __switch_to_asm+0x40/0x70
&lt;4&gt;[  110.152501]  ? __switch_to_asm+0x34/0x70
&lt;4&gt;[  110.152511]  ? __switch_to_asm+0x40/0x70
&lt;4&gt;[  110.152522]  ? __switch_to_asm+0x34/0x70
&lt;4&gt;[  110.152533]  recv_work+0x35/0x9e [nbd]
&lt;4&gt;[  110.152547]  process_one_work+0x19d/0x340
&lt;4&gt;[  110.152558]  worker_thread+0x50/0x3b0
&lt;4&gt;[  110.152568]  kthread+0xfb/0x130
&lt;4&gt;[  110.152577]  ? process_one_work+0x340/0x340
&lt;4&gt;[  110.152609]  ? kthread_park+0x80/0x80
&lt;4&gt;[  110.152637]  ret_from_fork+0x35/0x40

This is very easy to reproduce by running the nbd-runner.

Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Signed-off-by: Xiubo Li &lt;xiubli@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nbd: rename the runtime flags as NBD_RT_ prefixed</title>
<updated>2019-09-18T02:03:49+00:00</updated>
<author>
<name>Xiubo Li</name>
<email>xiubli@redhat.com</email>
</author>
<published>2019-09-17T11:56:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ec76a7b922e42df1437e39b44c564ba892676f0e'/>
<id>ec76a7b922e42df1437e39b44c564ba892676f0e</id>
<content type='text'>
Preparing for the destory when disconnecting crash fixing.

Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Signed-off-by: Xiubo Li &lt;xiubli@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Preparing for the destory when disconnecting crash fixing.

Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Signed-off-by: Xiubo Li &lt;xiubli@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nbd: fix max number of supported devs</title>
<updated>2019-08-20T18:44:07+00:00</updated>
<author>
<name>Mike Christie</name>
<email>mchristi@redhat.com</email>
</author>
<published>2019-08-04T19:10:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e9e006f5fcf2bab59149cb38a48a4817c1b538b4'/>
<id>e9e006f5fcf2bab59149cb38a48a4817c1b538b4</id>
<content type='text'>
This fixes a bug added in 4.10 with commit:

commit 9561a7ade0c205bc2ee035a2ac880478dcc1a024
Author: Josef Bacik &lt;jbacik@fb.com&gt;
Date:   Tue Nov 22 14:04:40 2016 -0500

    nbd: add multi-connection support

that limited the number of devices to 256. Before the patch we could
create 1000s of devices, but the patch switched us from using our
own thread to using a work queue which has a default limit of 256
active works.

The problem is that our recv_work function sits in a loop until
disconnection but only handles IO for one connection. The work is
started when the connection is started/restarted, but if we end up
creating 257 or more connections, the queue_work call just queues
connection257+'s recv_work and that waits for connection 1 - 256's
recv_work to be disconnected and that work instance completing.

Instead of reverting back to kthreads, this has us allocate a
workqueue_struct per device, so we can block in the work.

Cc: stable@vger.kernel.org
Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Signed-off-by: Mike Christie &lt;mchristi@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes a bug added in 4.10 with commit:

commit 9561a7ade0c205bc2ee035a2ac880478dcc1a024
Author: Josef Bacik &lt;jbacik@fb.com&gt;
Date:   Tue Nov 22 14:04:40 2016 -0500

    nbd: add multi-connection support

that limited the number of devices to 256. Before the patch we could
create 1000s of devices, but the patch switched us from using our
own thread to using a work queue which has a default limit of 256
active works.

The problem is that our recv_work function sits in a loop until
disconnection but only handles IO for one connection. The work is
started when the connection is started/restarted, but if we end up
creating 257 or more connections, the queue_work call just queues
connection257+'s recv_work and that waits for connection 1 - 256's
recv_work to be disconnected and that work instance completing.

Instead of reverting back to kthreads, this has us allocate a
workqueue_struct per device, so we can block in the work.

Cc: stable@vger.kernel.org
Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Signed-off-by: Mike Christie &lt;mchristi@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nbd: fix zero cmd timeout handling v2</title>
<updated>2019-08-20T18:44:05+00:00</updated>
<author>
<name>Mike Christie</name>
<email>mchristi@redhat.com</email>
</author>
<published>2019-08-13T16:39:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2da22da573481cc4837e246d0eee4d518b3f715e'/>
<id>2da22da573481cc4837e246d0eee4d518b3f715e</id>
<content type='text'>
This fixes a regression added in 4.9 with commit:

commit 0eadf37afc2500e1162c9040ec26a705b9af8d47
Author: Josef Bacik &lt;jbacik@fb.com&gt;
Date:   Thu Sep 8 12:33:40 2016 -0700

    nbd: allow block mq to deal with timeouts

where before the patch userspace would set the timeout to 0 to disable
it. With the above patch, a zero timeout tells the block layer to use
the default value of 30 seconds. For setups where commands can take a
long time or experience transient issues like network disruptions this
then results in IO errors being sent to the application.

To fix this, the patch still uses the common block layer timeout
framework, but if zero is set, nbd just logs a message and then resets
the timer when it expires.

Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Signed-off-by: Mike Christie &lt;mchristi@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes a regression added in 4.9 with commit:

commit 0eadf37afc2500e1162c9040ec26a705b9af8d47
Author: Josef Bacik &lt;jbacik@fb.com&gt;
Date:   Thu Sep 8 12:33:40 2016 -0700

    nbd: allow block mq to deal with timeouts

where before the patch userspace would set the timeout to 0 to disable
it. With the above patch, a zero timeout tells the block layer to use
the default value of 30 seconds. For setups where commands can take a
long time or experience transient issues like network disruptions this
then results in IO errors being sent to the application.

To fix this, the patch still uses the common block layer timeout
framework, but if zero is set, nbd just logs a message and then resets
the timer when it expires.

Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Signed-off-by: Mike Christie &lt;mchristi@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nbd: add missing config put</title>
<updated>2019-08-20T18:44:04+00:00</updated>
<author>
<name>Mike Christie</name>
<email>mchristi@redhat.com</email>
</author>
<published>2019-08-13T16:39:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=887e975c4172d0d5670c39ead2f18ba1e4ec8133'/>
<id>887e975c4172d0d5670c39ead2f18ba1e4ec8133</id>
<content type='text'>
Fix bug added with the patch:

commit 8f3ea35929a0806ad1397db99a89ffee0140822a
Author: Josef Bacik &lt;josef@toxicpanda.com&gt;
Date:   Mon Jul 16 12:11:35 2018 -0400

    nbd: handle unexpected replies better

where if the timeout handler runs when the completion path is and we fail
to grab the mutex in the timeout handler we will leave a config reference
and cannot free the config later.

Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Signed-off-by: Mike Christie &lt;mchristi@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix bug added with the patch:

commit 8f3ea35929a0806ad1397db99a89ffee0140822a
Author: Josef Bacik &lt;josef@toxicpanda.com&gt;
Date:   Mon Jul 16 12:11:35 2018 -0400

    nbd: handle unexpected replies better

where if the timeout handler runs when the completion path is and we fail
to grab the mutex in the timeout handler we will leave a config reference
and cannot free the config later.

Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Signed-off-by: Mike Christie &lt;mchristi@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</pre>
</div>
</content>
</entry>
</feed>
