<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/block, branch v3.10.51</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>blkcg: don't call into policy draining if root_blkg is already gone</title>
<updated>2014-07-31T19:53:49+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2014-07-05T22:43:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cebdb6fa24dfd48af3bba1af6ba485b45430fb1c'/>
<id>cebdb6fa24dfd48af3bba1af6ba485b45430fb1c</id>
<content type='text'>
commit 0b462c89e31f7eb6789713437eb551833ee16ff3 upstream.

While a queue is being destroyed, all the blkgs are destroyed and its
-&gt;root_blkg pointer is set to NULL.  If someone else starts to drain
while the queue is in this state, the following oops happens.

  NULL pointer dereference at 0000000000000028
  IP: [&lt;ffffffff8144e944&gt;] blk_throtl_drain+0x84/0x230
  PGD e4a1067 PUD b773067 PMD 0
  Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
  Modules linked in: cfq_iosched(-) [last unloaded: cfq_iosched]
  CPU: 1 PID: 537 Comm: bash Not tainted 3.16.0-rc3-work+ #2
  Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  task: ffff88000e222250 ti: ffff88000efd4000 task.ti: ffff88000efd4000
  RIP: 0010:[&lt;ffffffff8144e944&gt;]  [&lt;ffffffff8144e944&gt;] blk_throtl_drain+0x84/0x230
  RSP: 0018:ffff88000efd7bf0  EFLAGS: 00010046
  RAX: 0000000000000000 RBX: ffff880015091450 RCX: 0000000000000001
  RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
  RBP: ffff88000efd7c10 R08: 0000000000000000 R09: 0000000000000001
  R10: ffff88000e222250 R11: 0000000000000000 R12: ffff880015091450
  R13: ffff880015092e00 R14: ffff880015091d70 R15: ffff88001508fc28
  FS:  00007f1332650740(0000) GS:ffff88001fa80000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 0000000000000028 CR3: 0000000009446000 CR4: 00000000000006e0
  Stack:
   ffffffff8144e8f6 ffff880015091450 0000000000000000 ffff880015091d80
   ffff88000efd7c28 ffffffff8144ae2f ffff880015091450 ffff88000efd7c58
   ffffffff81427641 ffff880015091450 ffffffff82401f00 ffff880015091450
  Call Trace:
   [&lt;ffffffff8144ae2f&gt;] blkcg_drain_queue+0x1f/0x60
   [&lt;ffffffff81427641&gt;] __blk_drain_queue+0x71/0x180
   [&lt;ffffffff81429b3e&gt;] blk_queue_bypass_start+0x6e/0xb0
   [&lt;ffffffff814498b8&gt;] blkcg_deactivate_policy+0x38/0x120
   [&lt;ffffffff8144ec44&gt;] blk_throtl_exit+0x34/0x50
   [&lt;ffffffff8144aea5&gt;] blkcg_exit_queue+0x35/0x40
   [&lt;ffffffff8142d476&gt;] blk_release_queue+0x26/0xd0
   [&lt;ffffffff81454968&gt;] kobject_cleanup+0x38/0x70
   [&lt;ffffffff81454848&gt;] kobject_put+0x28/0x60
   [&lt;ffffffff81427505&gt;] blk_put_queue+0x15/0x20
   [&lt;ffffffff817d07bb&gt;] scsi_device_dev_release_usercontext+0x16b/0x1c0
   [&lt;ffffffff810bc339&gt;] execute_in_process_context+0x89/0xa0
   [&lt;ffffffff817d064c&gt;] scsi_device_dev_release+0x1c/0x20
   [&lt;ffffffff817930e2&gt;] device_release+0x32/0xa0
   [&lt;ffffffff81454968&gt;] kobject_cleanup+0x38/0x70
   [&lt;ffffffff81454848&gt;] kobject_put+0x28/0x60
   [&lt;ffffffff817934d7&gt;] put_device+0x17/0x20
   [&lt;ffffffff817d11b9&gt;] __scsi_remove_device+0xa9/0xe0
   [&lt;ffffffff817d121b&gt;] scsi_remove_device+0x2b/0x40
   [&lt;ffffffff817d1257&gt;] sdev_store_delete+0x27/0x30
   [&lt;ffffffff81792ca8&gt;] dev_attr_store+0x18/0x30
   [&lt;ffffffff8126f75e&gt;] sysfs_kf_write+0x3e/0x50
   [&lt;ffffffff8126ea87&gt;] kernfs_fop_write+0xe7/0x170
   [&lt;ffffffff811f5e9f&gt;] vfs_write+0xaf/0x1d0
   [&lt;ffffffff811f69bd&gt;] SyS_write+0x4d/0xc0
   [&lt;ffffffff81d24692&gt;] system_call_fastpath+0x16/0x1b

776687bce42b ("block, blk-mq: draining can't be skipped even if
bypass_depth was non-zero") made it easier to trigger this bug by
making blk_queue_bypass_start() drain even when it loses the first
bypass test to blk_cleanup_queue(); however, the bug has always been
there even before the commit as blk_queue_bypass_start() could race
against queue destruction, win the initial bypass test but perform the
actual draining after blk_cleanup_queue() already destroyed all blkgs.

Fix it by skippping calling into policy draining if all the blkgs are
already gone.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: Shirish Pargaonkar &lt;spargaonkar@suse.com&gt;
Reported-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Reported-by: Jet Chen &lt;jet.chen@intel.com&gt;
Tested-by: Shirish Pargaonkar &lt;spargaonkar@suse.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.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 0b462c89e31f7eb6789713437eb551833ee16ff3 upstream.

While a queue is being destroyed, all the blkgs are destroyed and its
-&gt;root_blkg pointer is set to NULL.  If someone else starts to drain
while the queue is in this state, the following oops happens.

  NULL pointer dereference at 0000000000000028
  IP: [&lt;ffffffff8144e944&gt;] blk_throtl_drain+0x84/0x230
  PGD e4a1067 PUD b773067 PMD 0
  Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
  Modules linked in: cfq_iosched(-) [last unloaded: cfq_iosched]
  CPU: 1 PID: 537 Comm: bash Not tainted 3.16.0-rc3-work+ #2
  Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  task: ffff88000e222250 ti: ffff88000efd4000 task.ti: ffff88000efd4000
  RIP: 0010:[&lt;ffffffff8144e944&gt;]  [&lt;ffffffff8144e944&gt;] blk_throtl_drain+0x84/0x230
  RSP: 0018:ffff88000efd7bf0  EFLAGS: 00010046
  RAX: 0000000000000000 RBX: ffff880015091450 RCX: 0000000000000001
  RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
  RBP: ffff88000efd7c10 R08: 0000000000000000 R09: 0000000000000001
  R10: ffff88000e222250 R11: 0000000000000000 R12: ffff880015091450
  R13: ffff880015092e00 R14: ffff880015091d70 R15: ffff88001508fc28
  FS:  00007f1332650740(0000) GS:ffff88001fa80000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 0000000000000028 CR3: 0000000009446000 CR4: 00000000000006e0
  Stack:
   ffffffff8144e8f6 ffff880015091450 0000000000000000 ffff880015091d80
   ffff88000efd7c28 ffffffff8144ae2f ffff880015091450 ffff88000efd7c58
   ffffffff81427641 ffff880015091450 ffffffff82401f00 ffff880015091450
  Call Trace:
   [&lt;ffffffff8144ae2f&gt;] blkcg_drain_queue+0x1f/0x60
   [&lt;ffffffff81427641&gt;] __blk_drain_queue+0x71/0x180
   [&lt;ffffffff81429b3e&gt;] blk_queue_bypass_start+0x6e/0xb0
   [&lt;ffffffff814498b8&gt;] blkcg_deactivate_policy+0x38/0x120
   [&lt;ffffffff8144ec44&gt;] blk_throtl_exit+0x34/0x50
   [&lt;ffffffff8144aea5&gt;] blkcg_exit_queue+0x35/0x40
   [&lt;ffffffff8142d476&gt;] blk_release_queue+0x26/0xd0
   [&lt;ffffffff81454968&gt;] kobject_cleanup+0x38/0x70
   [&lt;ffffffff81454848&gt;] kobject_put+0x28/0x60
   [&lt;ffffffff81427505&gt;] blk_put_queue+0x15/0x20
   [&lt;ffffffff817d07bb&gt;] scsi_device_dev_release_usercontext+0x16b/0x1c0
   [&lt;ffffffff810bc339&gt;] execute_in_process_context+0x89/0xa0
   [&lt;ffffffff817d064c&gt;] scsi_device_dev_release+0x1c/0x20
   [&lt;ffffffff817930e2&gt;] device_release+0x32/0xa0
   [&lt;ffffffff81454968&gt;] kobject_cleanup+0x38/0x70
   [&lt;ffffffff81454848&gt;] kobject_put+0x28/0x60
   [&lt;ffffffff817934d7&gt;] put_device+0x17/0x20
   [&lt;ffffffff817d11b9&gt;] __scsi_remove_device+0xa9/0xe0
   [&lt;ffffffff817d121b&gt;] scsi_remove_device+0x2b/0x40
   [&lt;ffffffff817d1257&gt;] sdev_store_delete+0x27/0x30
   [&lt;ffffffff81792ca8&gt;] dev_attr_store+0x18/0x30
   [&lt;ffffffff8126f75e&gt;] sysfs_kf_write+0x3e/0x50
   [&lt;ffffffff8126ea87&gt;] kernfs_fop_write+0xe7/0x170
   [&lt;ffffffff811f5e9f&gt;] vfs_write+0xaf/0x1d0
   [&lt;ffffffff811f69bd&gt;] SyS_write+0x4d/0xc0
   [&lt;ffffffff81d24692&gt;] system_call_fastpath+0x16/0x1b

776687bce42b ("block, blk-mq: draining can't be skipped even if
bypass_depth was non-zero") made it easier to trigger this bug by
making blk_queue_bypass_start() drain even when it loses the first
bypass test to blk_cleanup_queue(); however, the bug has always been
there even before the commit as blk_queue_bypass_start() could race
against queue destruction, win the initial bypass test but perform the
actual draining after blk_cleanup_queue() already destroyed all blkgs.

Fix it by skippping calling into policy draining if all the blkgs are
already gone.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: Shirish Pargaonkar &lt;spargaonkar@suse.com&gt;
Reported-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Reported-by: Jet Chen &lt;jet.chen@intel.com&gt;
Tested-by: Shirish Pargaonkar &lt;spargaonkar@suse.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>block: don't assume last put of shared tags is for the host</title>
<updated>2014-07-31T19:53:48+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2014-07-08T10:25:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cb454b6d31756674d2e0ceaa336ec87019728d9b'/>
<id>cb454b6d31756674d2e0ceaa336ec87019728d9b</id>
<content type='text'>
commit d45b3279a5a2252cafcd665bbf2db8c9b31ef783 upstream.

There is no inherent reason why the last put of a tag structure must be
the one for the Scsi_Host, as device model objects can be held for
arbitrary periods.  Merge blk_free_tags and __blk_free_tags into a single
funtion that just release a references and get rid of the BUG() when the
host reference wasn't the last.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.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 d45b3279a5a2252cafcd665bbf2db8c9b31ef783 upstream.

There is no inherent reason why the last put of a tag structure must be
the one for the Scsi_Host, as device model objects can be held for
arbitrary periods.  Merge blk_free_tags and __blk_free_tags into a single
funtion that just release a references and get rid of the BUG() when the
host reference wasn't the last.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>block: provide compat ioctl for BLKZEROOUT</title>
<updated>2014-07-31T19:53:48+00:00</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2014-07-02T16:46:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=668b7a05f2fa59c60ca9820269e3d8dfaa218693'/>
<id>668b7a05f2fa59c60ca9820269e3d8dfaa218693</id>
<content type='text'>
commit 3b3a1814d1703027f9867d0f5cbbfaf6c7482474 upstream.

This patch provides the compat BLKZEROOUT ioctl. The argument is a pointer
to two uint64_t values, so there is no need to translate it.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Acked-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.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 3b3a1814d1703027f9867d0f5cbbfaf6c7482474 upstream.

This patch provides the compat BLKZEROOUT ioctl. The argument is a pointer
to two uint64_t values, so there is no need to translate it.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Acked-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>blktrace: fix accounting of partially completed requests</title>
<updated>2014-05-31T04:52:11+00:00</updated>
<author>
<name>Roman Pen</name>
<email>r.peniaev@gmail.com</email>
</author>
<published>2014-03-04T14:13:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e9d933941569c107e0083c3c115467c699a57db2'/>
<id>e9d933941569c107e0083c3c115467c699a57db2</id>
<content type='text'>
commit af5040da01ef980670b3741b3e10733ee3e33566 upstream.

trace_block_rq_complete does not take into account that request can
be partially completed, so we can get the following incorrect output
of blkparser:

  C   R 232 + 240 [0]
  C   R 240 + 232 [0]
  C   R 248 + 224 [0]
  C   R 256 + 216 [0]

but should be:

  C   R 232 + 8 [0]
  C   R 240 + 8 [0]
  C   R 248 + 8 [0]
  C   R 256 + 8 [0]

Also, the whole output summary statistics of completed requests and
final throughput will be incorrect.

This patch takes into account real completion size of the request and
fixes wrong completion accounting.

Signed-off-by: Roman Pen &lt;r.peniaev@gmail.com&gt;
CC: Steven Rostedt &lt;rostedt@goodmis.org&gt;
CC: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
CC: Ingo Molnar &lt;mingo@redhat.com&gt;
CC: linux-kernel@vger.kernel.org
Signed-off-by: Jens Axboe &lt;axboe@fb.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 af5040da01ef980670b3741b3e10733ee3e33566 upstream.

trace_block_rq_complete does not take into account that request can
be partially completed, so we can get the following incorrect output
of blkparser:

  C   R 232 + 240 [0]
  C   R 240 + 232 [0]
  C   R 248 + 224 [0]
  C   R 256 + 216 [0]

but should be:

  C   R 232 + 8 [0]
  C   R 240 + 8 [0]
  C   R 248 + 8 [0]
  C   R 256 + 8 [0]

Also, the whole output summary statistics of completed requests and
final throughput will be incorrect.

This patch takes into account real completion size of the request and
fixes wrong completion accounting.

Signed-off-by: Roman Pen &lt;r.peniaev@gmail.com&gt;
CC: Steven Rostedt &lt;rostedt@goodmis.org&gt;
CC: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
CC: Ingo Molnar &lt;mingo@redhat.com&gt;
CC: linux-kernel@vger.kernel.org
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>block: add cond_resched() to potentially long running ioctl discard loop</title>
<updated>2014-02-22T20:41:28+00:00</updated>
<author>
<name>Jens Axboe</name>
<email>axboe@fb.com</email>
</author>
<published>2014-02-12T16:34:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=163d66d4fb1009d51027286cc4b921a5928961fc'/>
<id>163d66d4fb1009d51027286cc4b921a5928961fc</id>
<content type='text'>
commit c8123f8c9cb517403b51aa41c3c46ff5e10b2c17 upstream.

When mkfs issues a full device discard and the device only
supports discards of a smallish size, we can loop in
blkdev_issue_discard() for a long time. If preempt isn't enabled,
this can turn into a softlock situation and the kernel will
start complaining.

Add an explicit cond_resched() at the end of the loop to avoid
that.

Signed-off-by: Jens Axboe &lt;axboe@fb.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 c8123f8c9cb517403b51aa41c3c46ff5e10b2c17 upstream.

When mkfs issues a full device discard and the device only
supports discards of a smallish size, we can loop in
blkdev_issue_discard() for a long time. If preempt isn't enabled,
this can turn into a softlock situation and the kernel will
start complaining.

Add an explicit cond_resched() at the end of the loop to avoid
that.

Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>block: __elv_next_request() shouldn't call into the elevator if bypassing</title>
<updated>2014-02-22T20:41:28+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2014-01-29T21:56:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=404ced25b4212bcaaa2de3be6861433587717bbf'/>
<id>404ced25b4212bcaaa2de3be6861433587717bbf</id>
<content type='text'>
commit 556ee818c06f37b2e583af0363e6b16d0e0270de upstream.

request_queue bypassing is used to suppress higher-level function of a
request_queue so that they can be switched, reconfigured and shut
down.  A request_queue does the followings while bypassing.

* bypasses elevator and io_cq association and queues requests directly
  to the FIFO dispatch queue.

* bypasses block cgroup request_list lookup and always uses the root
  request_list.

Once confirmed to be bypassing, specific elevator and block cgroup
policy implementations can assume that nothing is in flight for them
and perform various operations which would be dangerous otherwise.

Such confirmation is acheived by short-circuiting all new requests
directly to the dispatch queue and waiting for all the requests which
were issued before to finish.  Unfortunately, while the request
allocating and draining sides were properly handled, we forgot to
actually plug the request dispatch path.  Even after bypassing mode is
confirmed, if the attached driver tries to fetch a request and the
dispatch queue is empty, __elv_next_request() would invoke the current
elevator's elevator_dispatch_fn() callback.  As all in-flight requests
were drained, the elevator wouldn't contain any request but once
bypass is confirmed we don't even know whether the elevator is even
there.  It might be in the process of being switched and half torn
down.

Frank Mayhar reports that this actually happened while switching
elevators, leading to an oops.

Let's fix it by making __elv_next_request() avoid invoking the
elevator_dispatch_fn() callback if the queue is bypassing.  It already
avoids invoking the callback if the queue is dying.  As a dying queue
is guaranteed to be bypassing, we can simply replace blk_queue_dying()
check with blk_queue_bypass().

Reported-by: Frank Mayhar &lt;fmayhar@google.com&gt;
References: http://lkml.kernel.org/g/1390319905.20232.38.camel@bobble.lax.corp.google.com
Tested-by: Frank Mayhar &lt;fmayhar@google.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&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 556ee818c06f37b2e583af0363e6b16d0e0270de upstream.

request_queue bypassing is used to suppress higher-level function of a
request_queue so that they can be switched, reconfigured and shut
down.  A request_queue does the followings while bypassing.

* bypasses elevator and io_cq association and queues requests directly
  to the FIFO dispatch queue.

* bypasses block cgroup request_list lookup and always uses the root
  request_list.

Once confirmed to be bypassing, specific elevator and block cgroup
policy implementations can assume that nothing is in flight for them
and perform various operations which would be dangerous otherwise.

Such confirmation is acheived by short-circuiting all new requests
directly to the dispatch queue and waiting for all the requests which
were issued before to finish.  Unfortunately, while the request
allocating and draining sides were properly handled, we forgot to
actually plug the request dispatch path.  Even after bypassing mode is
confirmed, if the attached driver tries to fetch a request and the
dispatch queue is empty, __elv_next_request() would invoke the current
elevator's elevator_dispatch_fn() callback.  As all in-flight requests
were drained, the elevator wouldn't contain any request but once
bypass is confirmed we don't even know whether the elevator is even
there.  It might be in the process of being switched and half torn
down.

Frank Mayhar reports that this actually happened while switching
elevators, leading to an oops.

Let's fix it by making __elv_next_request() avoid invoking the
elevator_dispatch_fn() callback if the queue is bypassing.  It already
avoids invoking the callback if the queue is dying.  As a dying queue
is guaranteed to be bypassing, we can simply replace blk_queue_dying()
check with blk_queue_bypass().

Reported-by: Frank Mayhar &lt;fmayhar@google.com&gt;
References: http://lkml.kernel.org/g/1390319905.20232.38.camel@bobble.lax.corp.google.com
Tested-by: Frank Mayhar &lt;fmayhar@google.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Update of blkg_stat and blkg_rwstat may happen in bh context. While u64_stats_fetch_retry is only preempt_disable on 32bit UP system. This is not enough to avoid preemption by bh and may read strange 64 bit value.</title>
<updated>2013-12-12T06:36:27+00:00</updated>
<author>
<name>Hong Zhiguo</name>
<email>zhiguohong@tencent.com</email>
</author>
<published>2013-11-20T17:35:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=950cda7f8e2bc6f182a2640817970166c55240db'/>
<id>950cda7f8e2bc6f182a2640817970166c55240db</id>
<content type='text'>
commit 2c575026fae6e63771bd2a4c1d407214a8096a89 upstream.

Signed-off-by: Hong Zhiguo &lt;zhiguohong@tencent.com&gt;
Acked-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&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 2c575026fae6e63771bd2a4c1d407214a8096a89 upstream.

Signed-off-by: Hong Zhiguo &lt;zhiguohong@tencent.com&gt;
Acked-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>elevator: acquire q-&gt;sysfs_lock in elevator_change()</title>
<updated>2013-12-08T15:29:27+00:00</updated>
<author>
<name>Tomoki Sekiyama</name>
<email>tomoki.sekiyama@hds.com</email>
</author>
<published>2013-10-15T22:42:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=72b9401c2f5ac465d97969ef7933753642bde8bf'/>
<id>72b9401c2f5ac465d97969ef7933753642bde8bf</id>
<content type='text'>
commit 7c8a3679e3d8e9d92d58f282161760a0e247df97 upstream.

Add locking of q-&gt;sysfs_lock into elevator_change() (an exported function)
to ensure it is held to protect q-&gt;elevator from elevator_init(), even if
elevator_change() is called from non-sysfs paths.
sysfs path (elv_iosched_store) uses __elevator_change(), non-locking
version, as the lock is already taken by elv_iosched_store().

Signed-off-by: Tomoki Sekiyama &lt;tomoki.sekiyama@hds.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: Josh Boyer &lt;jwboyer@fedoraproject.org&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 7c8a3679e3d8e9d92d58f282161760a0e247df97 upstream.

Add locking of q-&gt;sysfs_lock into elevator_change() (an exported function)
to ensure it is held to protect q-&gt;elevator from elevator_init(), even if
elevator_change() is called from non-sysfs paths.
sysfs path (elv_iosched_store) uses __elevator_change(), non-locking
version, as the lock is already taken by elv_iosched_store().

Signed-off-by: Tomoki Sekiyama &lt;tomoki.sekiyama@hds.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: Josh Boyer &lt;jwboyer@fedoraproject.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>elevator: Fix a race in elevator switching and md device initialization</title>
<updated>2013-12-08T15:29:27+00:00</updated>
<author>
<name>Tomoki Sekiyama</name>
<email>tomoki.sekiyama@hds.com</email>
</author>
<published>2013-10-15T22:42:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6d53d39270ccd29938dcbd611a44870c63032521'/>
<id>6d53d39270ccd29938dcbd611a44870c63032521</id>
<content type='text'>
commit eb1c160b22655fd4ec44be732d6594fd1b1e44f4 upstream.

The soft lockup below happens at the boot time of the system using dm
multipath and the udev rules to switch scheduler.

[  356.127001] BUG: soft lockup - CPU#3 stuck for 22s! [sh:483]
[  356.127001] RIP: 0010:[&lt;ffffffff81072a7d&gt;]  [&lt;ffffffff81072a7d&gt;] lock_timer_base.isra.35+0x1d/0x50
...
[  356.127001] Call Trace:
[  356.127001]  [&lt;ffffffff81073810&gt;] try_to_del_timer_sync+0x20/0x70
[  356.127001]  [&lt;ffffffff8118b08a&gt;] ? kmem_cache_alloc_node_trace+0x20a/0x230
[  356.127001]  [&lt;ffffffff810738b2&gt;] del_timer_sync+0x52/0x60
[  356.127001]  [&lt;ffffffff812ece22&gt;] cfq_exit_queue+0x32/0xf0
[  356.127001]  [&lt;ffffffff812c98df&gt;] elevator_exit+0x2f/0x50
[  356.127001]  [&lt;ffffffff812c9f21&gt;] elevator_change+0xf1/0x1c0
[  356.127001]  [&lt;ffffffff812caa50&gt;] elv_iosched_store+0x20/0x50
[  356.127001]  [&lt;ffffffff812d1d09&gt;] queue_attr_store+0x59/0xb0
[  356.127001]  [&lt;ffffffff812143f6&gt;] sysfs_write_file+0xc6/0x140
[  356.127001]  [&lt;ffffffff811a326d&gt;] vfs_write+0xbd/0x1e0
[  356.127001]  [&lt;ffffffff811a3ca9&gt;] SyS_write+0x49/0xa0
[  356.127001]  [&lt;ffffffff8164e899&gt;] system_call_fastpath+0x16/0x1b

This is caused by a race between md device initialization by multipathd and
shell script to switch the scheduler using sysfs.

 - multipathd:
   SyS_ioctl -&gt; do_vfs_ioctl -&gt; dm_ctl_ioctl -&gt; ctl_ioctl -&gt; table_load
   -&gt; dm_setup_md_queue -&gt; blk_init_allocated_queue -&gt; elevator_init
    q-&gt;elevator = elevator_alloc(q, e); // not yet initialized

 - sh -c 'echo deadline &gt; /sys/$DEVPATH/queue/scheduler':
   elevator_switch (in the call trace above)
    struct elevator_queue *old = q-&gt;elevator;
    q-&gt;elevator = elevator_alloc(q, new_e);
    elevator_exit(old);                 // lockup! (*)

 - multipathd: (cont.)
    err = e-&gt;ops.elevator_init_fn(q);   // init fails; q-&gt;elevator is modified

(*) When del_timer_sync() is called, lock_timer_base() will loop infinitely
while timer-&gt;base == NULL. In this case, as timer will never initialized,
it results in lockup.

This patch introduces acquisition of q-&gt;sysfs_lock around elevator_init()
into blk_init_allocated_queue(), to provide mutual exclusion between
initialization of the q-&gt;scheduler and switching of the scheduler.

This should fix this bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=902012

Signed-off-by: Tomoki Sekiyama &lt;tomoki.sekiyama@hds.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&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 eb1c160b22655fd4ec44be732d6594fd1b1e44f4 upstream.

The soft lockup below happens at the boot time of the system using dm
multipath and the udev rules to switch scheduler.

[  356.127001] BUG: soft lockup - CPU#3 stuck for 22s! [sh:483]
[  356.127001] RIP: 0010:[&lt;ffffffff81072a7d&gt;]  [&lt;ffffffff81072a7d&gt;] lock_timer_base.isra.35+0x1d/0x50
...
[  356.127001] Call Trace:
[  356.127001]  [&lt;ffffffff81073810&gt;] try_to_del_timer_sync+0x20/0x70
[  356.127001]  [&lt;ffffffff8118b08a&gt;] ? kmem_cache_alloc_node_trace+0x20a/0x230
[  356.127001]  [&lt;ffffffff810738b2&gt;] del_timer_sync+0x52/0x60
[  356.127001]  [&lt;ffffffff812ece22&gt;] cfq_exit_queue+0x32/0xf0
[  356.127001]  [&lt;ffffffff812c98df&gt;] elevator_exit+0x2f/0x50
[  356.127001]  [&lt;ffffffff812c9f21&gt;] elevator_change+0xf1/0x1c0
[  356.127001]  [&lt;ffffffff812caa50&gt;] elv_iosched_store+0x20/0x50
[  356.127001]  [&lt;ffffffff812d1d09&gt;] queue_attr_store+0x59/0xb0
[  356.127001]  [&lt;ffffffff812143f6&gt;] sysfs_write_file+0xc6/0x140
[  356.127001]  [&lt;ffffffff811a326d&gt;] vfs_write+0xbd/0x1e0
[  356.127001]  [&lt;ffffffff811a3ca9&gt;] SyS_write+0x49/0xa0
[  356.127001]  [&lt;ffffffff8164e899&gt;] system_call_fastpath+0x16/0x1b

This is caused by a race between md device initialization by multipathd and
shell script to switch the scheduler using sysfs.

 - multipathd:
   SyS_ioctl -&gt; do_vfs_ioctl -&gt; dm_ctl_ioctl -&gt; ctl_ioctl -&gt; table_load
   -&gt; dm_setup_md_queue -&gt; blk_init_allocated_queue -&gt; elevator_init
    q-&gt;elevator = elevator_alloc(q, e); // not yet initialized

 - sh -c 'echo deadline &gt; /sys/$DEVPATH/queue/scheduler':
   elevator_switch (in the call trace above)
    struct elevator_queue *old = q-&gt;elevator;
    q-&gt;elevator = elevator_alloc(q, new_e);
    elevator_exit(old);                 // lockup! (*)

 - multipathd: (cont.)
    err = e-&gt;ops.elevator_init_fn(q);   // init fails; q-&gt;elevator is modified

(*) When del_timer_sync() is called, lock_timer_base() will loop infinitely
while timer-&gt;base == NULL. In this case, as timer will never initialized,
it results in lockup.

This patch introduces acquisition of q-&gt;sysfs_lock around elevator_init()
into blk_init_allocated_queue(), to provide mutual exclusion between
initialization of the q-&gt;scheduler and switching of the scheduler.

This should fix this bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=902012

Signed-off-by: Tomoki Sekiyama &lt;tomoki.sekiyama@hds.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>blk-core: Fix memory corruption if blkcg_init_queue fails</title>
<updated>2013-12-04T18:56:46+00:00</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2013-10-14T16:11:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d8db1a5f3133ec936bcbaced67890f229551d24f'/>
<id>d8db1a5f3133ec936bcbaced67890f229551d24f</id>
<content type='text'>
commit fff4996b7db7955414ac74386efa5e07fd766b50 upstream.

If blkcg_init_queue fails, blk_alloc_queue_node doesn't call bdi_destroy
to clean up structures allocated by the backing dev.

------------[ cut here ]------------
WARNING: at lib/debugobjects.c:260 debug_print_object+0x85/0xa0()
ODEBUG: free active (active state 0) object type: percpu_counter hint:           (null)
Modules linked in: dm_loop dm_mod ip6table_filter ip6_tables uvesafb cfbcopyarea cfbimgblt cfbfillrect fbcon font bitblit fbcon_rotate fbcon_cw fbcon_ud fbcon_ccw softcursor fb fbdev ipt_MASQUERADE iptable_nat nf_nat_ipv4 msr nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc tun ipv6 cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative spadfs fuse hid_generic usbhid hid raid0 md_mod dmi_sysfs nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack lm85 hwmon_vid snd_usb_audio snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_hwdep snd_usbmidi_lib snd_rawmidi snd soundcore acpi_cpufreq freq_table mperf sata_svw serverworks kvm_amd ide_core ehci_pci ohci_hcd libata ehci_hcd kvm usbcore tg3 usb_common libphy k10temp pcspkr ptp i2c_piix4 i2c_core evdev microcode hwmon rtc_cmos pps_core e100 skge floppy mii processor button unix
CPU: 0 PID: 2739 Comm: lvchange Tainted: G        W
3.10.15-devel #14
Hardware name: empty empty/S3992-E, BIOS 'V1.06   ' 06/09/2009
 0000000000000009 ffff88023c3c1ae8 ffffffff813c8fd4 ffff88023c3c1b20
 ffffffff810399eb ffff88043d35cd58 ffffffff81651940 ffff88023c3c1bf8
 ffffffff82479d90 0000000000000005 ffff88023c3c1b80 ffffffff81039a67
Call Trace:
 [&lt;ffffffff813c8fd4&gt;] dump_stack+0x19/0x1b
 [&lt;ffffffff810399eb&gt;] warn_slowpath_common+0x6b/0xa0
 [&lt;ffffffff81039a67&gt;] warn_slowpath_fmt+0x47/0x50
 [&lt;ffffffff8122aaaf&gt;] ? debug_check_no_obj_freed+0xcf/0x250
 [&lt;ffffffff81229a15&gt;] debug_print_object+0x85/0xa0
 [&lt;ffffffff8122abe3&gt;] debug_check_no_obj_freed+0x203/0x250
 [&lt;ffffffff8113c4ac&gt;] kmem_cache_free+0x20c/0x3a0
 [&lt;ffffffff811f6709&gt;] blk_alloc_queue_node+0x2a9/0x2c0
 [&lt;ffffffff811f672e&gt;] blk_alloc_queue+0xe/0x10
 [&lt;ffffffffa04c0093&gt;] dm_create+0x1a3/0x530 [dm_mod]
 [&lt;ffffffffa04c6bb0&gt;] ? list_version_get_info+0xe0/0xe0 [dm_mod]
 [&lt;ffffffffa04c6c07&gt;] dev_create+0x57/0x2b0 [dm_mod]
 [&lt;ffffffffa04c6bb0&gt;] ? list_version_get_info+0xe0/0xe0 [dm_mod]
 [&lt;ffffffffa04c6bb0&gt;] ? list_version_get_info+0xe0/0xe0 [dm_mod]
 [&lt;ffffffffa04c6528&gt;] ctl_ioctl+0x268/0x500 [dm_mod]
 [&lt;ffffffff81097662&gt;] ? get_lock_stats+0x22/0x70
 [&lt;ffffffffa04c67ce&gt;] dm_ctl_ioctl+0xe/0x20 [dm_mod]
 [&lt;ffffffff81161aad&gt;] do_vfs_ioctl+0x2ed/0x520
 [&lt;ffffffff8116cfc7&gt;] ? fget_light+0x377/0x4e0
 [&lt;ffffffff81161d2b&gt;] SyS_ioctl+0x4b/0x90
 [&lt;ffffffff813cff16&gt;] system_call_fastpath+0x1a/0x1f
---[ end trace 4b5ff0d55673d986 ]---
------------[ cut here ]------------

This fix should be backported to stable kernels starting with 2.6.37. Note
that in the kernels prior to 3.5 the affected code is different, but the
bug is still there - bdi_init is called and bdi_destroy isn't.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Acked-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&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 fff4996b7db7955414ac74386efa5e07fd766b50 upstream.

If blkcg_init_queue fails, blk_alloc_queue_node doesn't call bdi_destroy
to clean up structures allocated by the backing dev.

------------[ cut here ]------------
WARNING: at lib/debugobjects.c:260 debug_print_object+0x85/0xa0()
ODEBUG: free active (active state 0) object type: percpu_counter hint:           (null)
Modules linked in: dm_loop dm_mod ip6table_filter ip6_tables uvesafb cfbcopyarea cfbimgblt cfbfillrect fbcon font bitblit fbcon_rotate fbcon_cw fbcon_ud fbcon_ccw softcursor fb fbdev ipt_MASQUERADE iptable_nat nf_nat_ipv4 msr nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc tun ipv6 cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative spadfs fuse hid_generic usbhid hid raid0 md_mod dmi_sysfs nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack lm85 hwmon_vid snd_usb_audio snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_hwdep snd_usbmidi_lib snd_rawmidi snd soundcore acpi_cpufreq freq_table mperf sata_svw serverworks kvm_amd ide_core ehci_pci ohci_hcd libata ehci_hcd kvm usbcore tg3 usb_common libphy k10temp pcspkr ptp i2c_piix4 i2c_core evdev microcode hwmon rtc_cmos pps_core e100 skge floppy mii processor button unix
CPU: 0 PID: 2739 Comm: lvchange Tainted: G        W
3.10.15-devel #14
Hardware name: empty empty/S3992-E, BIOS 'V1.06   ' 06/09/2009
 0000000000000009 ffff88023c3c1ae8 ffffffff813c8fd4 ffff88023c3c1b20
 ffffffff810399eb ffff88043d35cd58 ffffffff81651940 ffff88023c3c1bf8
 ffffffff82479d90 0000000000000005 ffff88023c3c1b80 ffffffff81039a67
Call Trace:
 [&lt;ffffffff813c8fd4&gt;] dump_stack+0x19/0x1b
 [&lt;ffffffff810399eb&gt;] warn_slowpath_common+0x6b/0xa0
 [&lt;ffffffff81039a67&gt;] warn_slowpath_fmt+0x47/0x50
 [&lt;ffffffff8122aaaf&gt;] ? debug_check_no_obj_freed+0xcf/0x250
 [&lt;ffffffff81229a15&gt;] debug_print_object+0x85/0xa0
 [&lt;ffffffff8122abe3&gt;] debug_check_no_obj_freed+0x203/0x250
 [&lt;ffffffff8113c4ac&gt;] kmem_cache_free+0x20c/0x3a0
 [&lt;ffffffff811f6709&gt;] blk_alloc_queue_node+0x2a9/0x2c0
 [&lt;ffffffff811f672e&gt;] blk_alloc_queue+0xe/0x10
 [&lt;ffffffffa04c0093&gt;] dm_create+0x1a3/0x530 [dm_mod]
 [&lt;ffffffffa04c6bb0&gt;] ? list_version_get_info+0xe0/0xe0 [dm_mod]
 [&lt;ffffffffa04c6c07&gt;] dev_create+0x57/0x2b0 [dm_mod]
 [&lt;ffffffffa04c6bb0&gt;] ? list_version_get_info+0xe0/0xe0 [dm_mod]
 [&lt;ffffffffa04c6bb0&gt;] ? list_version_get_info+0xe0/0xe0 [dm_mod]
 [&lt;ffffffffa04c6528&gt;] ctl_ioctl+0x268/0x500 [dm_mod]
 [&lt;ffffffff81097662&gt;] ? get_lock_stats+0x22/0x70
 [&lt;ffffffffa04c67ce&gt;] dm_ctl_ioctl+0xe/0x20 [dm_mod]
 [&lt;ffffffff81161aad&gt;] do_vfs_ioctl+0x2ed/0x520
 [&lt;ffffffff8116cfc7&gt;] ? fget_light+0x377/0x4e0
 [&lt;ffffffff81161d2b&gt;] SyS_ioctl+0x4b/0x90
 [&lt;ffffffff813cff16&gt;] system_call_fastpath+0x1a/0x1f
---[ end trace 4b5ff0d55673d986 ]---
------------[ cut here ]------------

This fix should be backported to stable kernels starting with 2.6.37. Note
that in the kernels prior to 3.5 the affected code is different, but the
bug is still there - bdi_init is called and bdi_destroy isn't.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Acked-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
