<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/md, branch v3.8.4</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.8.4</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.8.4'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2013-03-14T18:26:22Z</updated>
<entry>
<title>md/raid1,raid10: fix deadlock with freeze_array()</title>
<updated>2013-03-14T18:26:22Z</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.de</email>
</author>
<published>2013-02-25T01:38:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=71192d4685c1a1fbaff5a1c6023095901bbb1cee'/>
<id>urn:sha1:71192d4685c1a1fbaff5a1c6023095901bbb1cee</id>
<content type='text'>
commit ee0b0244030434cdda26777bfb98962447e080cd upstream.

When raid1/raid10 needs to fix a read error, it first drains
all pending requests by calling freeze_array().
This calls flush_pending_writes() if it needs to sleep,
but some writes may be pending in a per-process plug rather
than in the per-array request queue.

When raid1{,0}_unplug() moves the request from the per-process
plug to the per-array request queue (from which
flush_pending_writes() can flush them), it needs to wake up
freeze_array(), or freeze_array() will never flush them and so
it will block forever.

So add the requires wake_up() calls.

This bug was introduced by commit
   f54a9d0e59c4bea3db733921ca9147612a6f292c
for raid1 and a similar commit for RAID10, and so has been present
since linux-3.6.  As the bug causes a deadlock I believe this fix is
suitable for -stable.

Reported-by: Tregaron Bayly &lt;tbayly@bluehost.com&gt;
Tested-by: Tregaron Bayly &lt;tbayly@bluehost.com&gt;
Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>md: raid0: fix error return from create_stripe_zones.</title>
<updated>2013-03-14T18:26:22Z</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.de</email>
</author>
<published>2013-02-21T04:36:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5260b2b544e14287a9d6eab457d89f1658356102'/>
<id>urn:sha1:5260b2b544e14287a9d6eab457d89f1658356102</id>
<content type='text'>
commit 58ebb34c49fcfcaa029e4b1c1453d92583900f9a upstream.

Create_stripe_zones returns an error slightly differently to
raid0_run and to raid0_takeover_*.

The error returned used by the second was wrong and an error would
result in mddev-&gt;private being set to NULL and sooner or later a
crash.

So never return NULL, return ERR_PTR(err), not NULL from
create_stripe_zones.

This bug has been present since 2.6.35 so the fix is suitable
for any kernel since then.

Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>md: fix two bugs when attempting to resize RAID0 array.</title>
<updated>2013-03-14T18:26:22Z</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.de</email>
</author>
<published>2013-02-21T03:33:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cac9a265334043f9500d385c358e07daa4636d7d'/>
<id>urn:sha1:cac9a265334043f9500d385c358e07daa4636d7d</id>
<content type='text'>
commit a64685399181780998281fe07309a94b25dd24c3 upstream.

You cannot resize a RAID0 array (in terms of making the devices
bigger), but the code doesn't entirely stop you.
So:

 disable setting of the available size on each device for
 RAID0 and Linear devices.  This must not change as doing so
 can change the effective layout of data.

 Make sure that the size that raid0_size() reports is accurate,
 but rounding devices sizes to chunk sizes.  As the device sizes
 cannot change now, this isn't so important, but it is best to be
 safe.

Without this change:
  mdadm --grow /dev/md0 -z max
  mdadm --grow /dev/md0 -Z max
  then read to the end of the array

can cause a BUG in a RAID0 array.

These bugs have been present ever since it became possible
to resize any device, which is a long time.  So the fix is
suitable for any -stable kerenl.

Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>md: protect against crash upon fsync on ro array</title>
<updated>2013-03-14T18:26:22Z</updated>
<author>
<name>Sebastian Riemer</name>
<email>sebastian.riemer@profitbricks.com</email>
</author>
<published>2013-02-21T02:28:09Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=22c776d64040e9ba838dd89e856bc7f5d73f46ba'/>
<id>urn:sha1:22c776d64040e9ba838dd89e856bc7f5d73f46ba</id>
<content type='text'>
commit bbfa57c0f2243a7c31fd248d22e9861a2802cad5 upstream.

If an fsync occurs on a read-only array, we need to send a
completion for the IO and may not increment the active IO count.
Otherwise, we hit a bug trace and can't stop the MD array anymore.

By advice of Christoph Hellwig we return success upon a flush
request but we return -EROFS for other writes.
We detect flush requests by checking if the bio has zero sectors.

This patch is suitable to any -stable kernel to which it applies.

Signed-off-by: Sebastian Riemer &lt;sebastian.riemer@profitbricks.com&gt;
Cc: Christoph Hellwig &lt;hch@infradead.org&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: NeilBrown &lt;neilb@suse.de&gt;
Reported-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Acked-by: Paul Menzel &lt;paulepanter@users.sourceforge.net&gt;
Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dm snapshot: add missing module aliases</title>
<updated>2013-03-14T18:26:12Z</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2013-03-01T22:45:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9de9853227dd16156a01f01ed7e7774d47dce0d1'/>
<id>urn:sha1:9de9853227dd16156a01f01ed7e7774d47dce0d1</id>
<content type='text'>
commit 23cb21092eb9dcec9d3604b68d95192b79915890 upstream.

Add module aliases so that autoloading works correctly if the user
tries to activate "snapshot-origin" or "snapshot-merge" targets.

Reference: https://bugzilla.redhat.com/889973

Reported-by: Chao Yang &lt;chyang@redhat.com&gt;
Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Alasdair G Kergon &lt;agk@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dm: fix limits initialization when there are no data devices</title>
<updated>2013-03-14T18:26:11Z</updated>
<author>
<name>Mike Christie</name>
<email>michaelc@cs.wisc.edu</email>
</author>
<published>2013-03-01T22:45:48Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6d2c84a053b338cb932d497b425cdc18845732f5'/>
<id>urn:sha1:6d2c84a053b338cb932d497b425cdc18845732f5</id>
<content type='text'>
commit 87eb5b21d92a92ac2da3163039d62df88c2b8422 upstream.

dm_calculate_queue_limits will first reset the provided limits to
defaults using blk_set_stacking_limits; whereby defeating the purpose of
retaining the original live table's limits -- as was intended via commit
3ae706561637331aa578e52bb89ecbba5edcb7a9 ("dm: retain table limits when
swapping to new table with no devices").

Fix this improper limits initialization (in the no data devices case) by
avoiding the call to dm_calculate_queue_limits.

[patch header revised by Mike Snitzer]

Signed-off-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Alasdair G Kergon &lt;agk@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dm: do not replace bioset for request based dm</title>
<updated>2013-03-14T18:26:11Z</updated>
<author>
<name>Jun'ichi Nomura</name>
<email>j-nomura@ce.jp.nec.com</email>
</author>
<published>2013-03-01T22:45:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f7ed89f011514839a5935629f27042edb2fdc981'/>
<id>urn:sha1:f7ed89f011514839a5935629f27042edb2fdc981</id>
<content type='text'>
commit 16245bdc9d3e22d1460341a655c8b5288953bc14 upstream.

This patch fixes a regression introduced in v3.8, which causes oops
like this when dm-multipath is used:

general protection fault: 0000 [#1] SMP
RIP: 0010:[&lt;ffffffff810fe754&gt;]  [&lt;ffffffff810fe754&gt;] mempool_free+0x24/0xb0
Call Trace:
  &lt;IRQ&gt;
  [&lt;ffffffff81187417&gt;] bio_put+0x97/0xc0
  [&lt;ffffffffa02247a5&gt;] end_clone_bio+0x35/0x90 [dm_mod]
  [&lt;ffffffff81185efd&gt;] bio_endio+0x1d/0x30
  [&lt;ffffffff811f03a3&gt;] req_bio_endio.isra.51+0xa3/0xe0
  [&lt;ffffffff811f2f68&gt;] blk_update_request+0x118/0x520
  [&lt;ffffffff811f3397&gt;] blk_update_bidi_request+0x27/0xa0
  [&lt;ffffffff811f343c&gt;] blk_end_bidi_request+0x2c/0x80
  [&lt;ffffffff811f34d0&gt;] blk_end_request+0x10/0x20
  [&lt;ffffffffa000b32b&gt;] scsi_io_completion+0xfb/0x6c0 [scsi_mod]
  [&lt;ffffffffa000107d&gt;] scsi_finish_command+0xbd/0x120 [scsi_mod]
  [&lt;ffffffffa000b12f&gt;] scsi_softirq_done+0x13f/0x160 [scsi_mod]
  [&lt;ffffffff811f9fd0&gt;] blk_done_softirq+0x80/0xa0
  [&lt;ffffffff81044551&gt;] __do_softirq+0xf1/0x250
  [&lt;ffffffff8142ee8c&gt;] call_softirq+0x1c/0x30
  [&lt;ffffffff8100420d&gt;] do_softirq+0x8d/0xc0
  [&lt;ffffffff81044885&gt;] irq_exit+0xd5/0xe0
  [&lt;ffffffff8142f3e3&gt;] do_IRQ+0x63/0xe0
  [&lt;ffffffff814257af&gt;] common_interrupt+0x6f/0x6f
  &lt;EOI&gt;
  [&lt;ffffffffa021737c&gt;] srp_queuecommand+0x8c/0xcb0 [ib_srp]
  [&lt;ffffffffa0002f18&gt;] scsi_dispatch_cmd+0x148/0x310 [scsi_mod]
  [&lt;ffffffffa000a38e&gt;] scsi_request_fn+0x31e/0x520 [scsi_mod]
  [&lt;ffffffff811f1e57&gt;] __blk_run_queue+0x37/0x50
  [&lt;ffffffff811f1f69&gt;] blk_delay_work+0x29/0x40
  [&lt;ffffffff81059003&gt;] process_one_work+0x1c3/0x5c0
  [&lt;ffffffff8105b22e&gt;] worker_thread+0x15e/0x440
  [&lt;ffffffff8106164b&gt;] kthread+0xdb/0xe0
  [&lt;ffffffff8142db9c&gt;] ret_from_fork+0x7c/0xb0

The regression was introduced by the change
c0820cf5 "dm: introduce per_bio_data", where dm started to replace
bioset during table replacement.
For bio-based dm, it is good because clone bios do not exist during the
table replacement.
For request-based dm, however, (not-yet-mapped) clone bios may stay in
request queue and survive during the table replacement.
So freeing the old bioset could cause the oops in bio_put().

Since the size of front_pad may change only with bio-based dm,
it is not necessary to replace bioset for request-based dm.

Reported-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Tested-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Jun'ichi Nomura &lt;j-nomura@ce.jp.nec.com&gt;
Acked-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Acked-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Alasdair G Kergon &lt;agk@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dm: fix truncated status strings</title>
<updated>2013-03-14T18:26:11Z</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2013-03-01T22:45:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a9317072827484b03a0959e85663d729537b8e05'/>
<id>urn:sha1:a9317072827484b03a0959e85663d729537b8e05</id>
<content type='text'>
commit fd7c092e711ebab55b2688d3859d95dfd0301f73 upstream.

Avoid returning a truncated table or status string instead of setting
the DM_BUFFER_FULL_FLAG when the last target of a table fills the
buffer.

When processing a table or status request, the function retrieve_status
calls ti-&gt;type-&gt;status. If ti-&gt;type-&gt;status returns non-zero,
retrieve_status assumes that the buffer overflowed and sets
DM_BUFFER_FULL_FLAG.

However, targets don't return non-zero values from their status method
on overflow. Most targets returns always zero.

If a buffer overflow happens in a target that is not the last in the
table, it gets noticed during the next iteration of the loop in
retrieve_status; but if a buffer overflow happens in the last target, it
goes unnoticed and erroneously truncated data is returned.

In the current code, the targets behave in the following way:
* dm-crypt returns -ENOMEM if there is not enough space to store the
  key, but it returns 0 on all other overflows.
* dm-thin returns errors from the status method if a disk error happened.
  This is incorrect because retrieve_status doesn't check the error
  code, it assumes that all non-zero values mean buffer overflow.
* all the other targets always return 0.

This patch changes the ti-&gt;type-&gt;status function to return void (because
most targets don't use the return code). Overflow is detected in
retrieve_status: if the status method fills up the remaining space
completely, it is assumed that buffer overflow happened.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Alasdair G Kergon &lt;agk@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge tag 'dm-3.8-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm</title>
<updated>2013-02-01T01:04:22Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-02-01T01:04:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cc6c954a076c5df7e0ac8d5e4ffa8b4f5572ae1d'/>
<id>urn:sha1:cc6c954a076c5df7e0ac8d5e4ffa8b4f5572ae1d</id>
<content type='text'>
Pull more device-mapper fixes from Alasdair G Kergon:
 "A fix for stacked dm thin devices and a fix for the new dm WRITE SAME
  support."

* tag 'dm-3.8-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm:
  dm: fix write same requests counting
  dm thin: fix queue limits stacking
</content>
</entry>
<entry>
<title>dm: fix write same requests counting</title>
<updated>2013-01-31T14:23:36Z</updated>
<author>
<name>Alasdair G Kergon</name>
<email>agk@redhat.com</email>
</author>
<published>2013-01-31T14:23:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fe7af2d3babefabd96a39e8b0d58ede88f3c7993'/>
<id>urn:sha1:fe7af2d3babefabd96a39e8b0d58ede88f3c7993</id>
<content type='text'>
When processing write same requests, fix dm to send the configured
number of WRITE SAME requests to the target rather than the number of
discards, which is not always the same.

Device-mapper WRITE SAME support was introduced by commit
23508a96cd2e857d57044a2ed7d305f2d9daf441 ("dm: add WRITE SAME support").

Signed-off-by: Alasdair G Kergon &lt;agk@redhat.com&gt;
Acked-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
</content>
</entry>
</feed>
