<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/md, branch v3.9</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/md?h=v3.9</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/md?h=v3.9'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-04-18T16:00:26Z</updated>
<entry>
<title>Revert "block: add missing block_bio_complete() tracepoint"</title>
<updated>2013-04-18T16:00:26Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-04-18T16:00:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0a82a8d132b26d438eb90b3ab35a7016e7227a1d'/>
<id>urn:sha1:0a82a8d132b26d438eb90b3ab35a7016e7227a1d</id>
<content type='text'>
This reverts commit 3a366e614d0837d9fc23f78cdb1a1186ebc3387f.

Wanlong Gao reports that it causes a kernel panic on his machine several
minutes after boot. Reverting it removes the panic.

Jens says:
 "It's not quite clear why that is yet, so I think we should just revert
  the commit for 3.9 final (which I'm assuming is pretty close).

  The wifi is crap at the LSF hotel, so sending this email instead of
  queueing up a revert and pull request."

Reported-by: Wanlong Gao &lt;gaowanlong@cn.fujitsu.com&gt;
Requested-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>dm cache: reduce bio front_pad size in writeback mode</title>
<updated>2013-04-05T14:36:34Z</updated>
<author>
<name>Mike Snitzer</name>
<email>snitzer@redhat.com</email>
</author>
<published>2013-04-05T14:36:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=19b0092e265fe9ab129902373c3127c0e0be3376'/>
<id>urn:sha1:19b0092e265fe9ab129902373c3127c0e0be3376</id>
<content type='text'>
A recent patch to fix the dm cache target's writethrough mode extended
the bio's front_pad to include a 1056-byte struct dm_bio_details.
Writeback mode doesn't need this, so this patch reduces the
per_bio_data_size to 16 bytes in this case instead of 1096.

The dm_bio_details structure was added in "dm cache: fix writes to
cache device in writethrough mode" which fixed commit e2e74d617e ("dm
cache: fix race in writethrough implementation").  In writeback mode
we avoid allocating the writethrough-specific members of the
per_bio_data structure (the dm_bio_details structure included).

Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Alasdair G Kergon &lt;agk@redhat.com&gt;
</content>
</entry>
<entry>
<title>dm cache: fix writes to cache device in writethrough mode</title>
<updated>2013-04-05T14:36:32Z</updated>
<author>
<name>Darrick J. Wong</name>
<email>darrick.wong@oracle.com</email>
</author>
<published>2013-04-05T14:36:32Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b844fe691897221ad0d5e0279c8ea9e3e4a46982'/>
<id>urn:sha1:b844fe691897221ad0d5e0279c8ea9e3e4a46982</id>
<content type='text'>
The dm-cache writethrough strategy introduced by commit e2e74d617eadc15
("dm cache: fix race in writethrough implementation") issues a bio to
the origin device, remaps and then issues the bio to the cache device.
This more conservative in-series approach was selected to favor
correctness over performance (of the previous parallel writethrough).
However, this in-series implementation that reuses the same bio to write
both the origin and cache device didn't take into account that the block
layer's req_bio_endio() modifies a completing bio's bi_sector and
bi_size.  So the new writethrough strategy needs to preserve these bio
fields, and restore them before submission to the cache device,
otherwise nothing gets written to the cache (because bi_size is 0).

This patch adds a struct dm_bio_details field to struct per_bio_data,
and uses dm_bio_record() and dm_bio_restore() to ensure the bio is
restored before reissuing to the cache device.  Adding such a large
structure to the per_bio_data is not ideal but we can improve this
later, for now correctness is the important thing.

This problem initially went unnoticed because the dm-cache test-suite
uses a linear DM device for the dm-cache device's origin device.
Writethrough worked as expected because DM submits a *clone* of the
original bio, so the original bio which was reused for the cache was
never touched.

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Signed-off-by: Joe Thornber &lt;ejt@redhat.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Alasdair G Kergon &lt;agk@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'md-3.9-fixes' of git://neil.brown.name/md</title>
<updated>2013-03-23T22:49:49Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-03-23T22:49:49Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=22c3f2fff68abf1ccf88e1a72f61bfede7b91da0'/>
<id>urn:sha1:22c3f2fff68abf1ccf88e1a72f61bfede7b91da0</id>
<content type='text'>
Pull md fixes from NeilBrown:
 "A few bugfixes for md

   - recent regressions in raid5
   - recent regressions in dmraid
   - a few instances of CONFIG_MULTICORE_RAID456 linger

  Several tagged for -stable"

* tag 'md-3.9-fixes' of git://neil.brown.name/md:
  md: remove CONFIG_MULTICORE_RAID456 entirely
  md/raid5: ensure sync and DISCARD don't happen at the same time.
  MD: Prevent sysfs operations on uninitialized kobjects
  MD RAID5: Avoid accessing gendisk or queue structs when not available
  md/raid5: schedule_construction should abort if nothing to do.
</content>
</entry>
<entry>
<title>dm cache: policy ignore hints if generated by different version</title>
<updated>2013-03-20T17:21:28Z</updated>
<author>
<name>Mike Snitzer</name>
<email>snitzer@redhat.com</email>
</author>
<published>2013-03-20T17:21:28Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ea2dd8c1ed0becee9812cf0840a9cd553ed398fe'/>
<id>urn:sha1:ea2dd8c1ed0becee9812cf0840a9cd553ed398fe</id>
<content type='text'>
When reading the dm cache metadata from disk, ignore the policy hints
unless they were generated by the same major version number of the same
policy module.

The hints are considered to be private data belonging to the specific
module that generated them and there is no requirement for them to make
sense to different versions of the policy that generated them.
Policy modules are all required to work fine if no previous hints are
supplied (or if existing hints are lost).

Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Alasdair G Kergon &lt;agk@redhat.com&gt;
</content>
</entry>
<entry>
<title>dm cache: policy change version from string to integer set</title>
<updated>2013-03-20T17:21:27Z</updated>
<author>
<name>Mike Snitzer</name>
<email>snitzer@redhat.com</email>
</author>
<published>2013-03-20T17:21:27Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4e7f506f6429636115e2f58f9f97089acc62524a'/>
<id>urn:sha1:4e7f506f6429636115e2f58f9f97089acc62524a</id>
<content type='text'>
Separate dm cache policy version string into 3 unsigned numbers
corresponding to major, minor and patchlevel and store them at the end
of the on-disk metadata so we know which version of the policy generated
the hints in case a future version wants to use them differently.

Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Alasdair G Kergon &lt;agk@redhat.com&gt;
</content>
</entry>
<entry>
<title>dm cache: fix race in writethrough implementation</title>
<updated>2013-03-20T17:21:27Z</updated>
<author>
<name>Joe Thornber</name>
<email>ejt@redhat.com</email>
</author>
<published>2013-03-20T17:21:27Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e2e74d617eadc15f601983270c4f4a6935c5a943'/>
<id>urn:sha1:e2e74d617eadc15f601983270c4f4a6935c5a943</id>
<content type='text'>
We have found a race in the optimisation used in the dm cache
writethrough implementation.  Currently, dm core sends the cache target
two bios, one for the origin device and one for the cache device and
these are processed in parallel.  This patch avoids the race by
changing the code back to a simpler (slower) implementation which
processes the two writes in series, one after the other, until we can
develop a complete fix for the problem.

When the cache is in writethrough mode it needs to send WRITE bios to
both the origin and cache devices.

Previously we've been implementing this by having dm core query the
cache target on every write to find out how many copies of the bio it
wants.  The cache will ask for two bios if the block is in the cache,
and one otherwise.

Then main problem with this is it's racey.  At the time this check is
made the bio hasn't yet been submitted and so isn't being taken into
account when quiescing a block for migration (promotion or demotion).
This means a single bio may be submitted when two were needed because
the block has since been promoted to the cache (catastrophic), or two
bios where only one is needed (harmless).

I really don't want to start entering bios into the quiescing system
(deferred_set) in the get_num_write_bios callback.  Instead this patch
simplifies things; only one bio is submitted by the core, this is
first written to the origin and then the cache device in series.
Obviously this will have a latency impact.

deferred_writethrough_bios is introduced to record bios that must be
later issued to the cache device from the worker thread.  This deferred
submission, after the origin bio completes, is required given that we're
in interrupt context (writethrough_endio).

Signed-off-by: Joe Thornber &lt;ejt@redhat.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Alasdair G Kergon &lt;agk@redhat.com&gt;
</content>
</entry>
<entry>
<title>dm cache: metadata clear dirty bits on clean shutdown</title>
<updated>2013-03-20T17:21:27Z</updated>
<author>
<name>Joe Thornber</name>
<email>ejt@redhat.com</email>
</author>
<published>2013-03-20T17:21:27Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=79ed9caffc9fff67aa64fd683e791aa70f1bcb51'/>
<id>urn:sha1:79ed9caffc9fff67aa64fd683e791aa70f1bcb51</id>
<content type='text'>
When writing the dirty bitset to the metadata device on a clean
shutdown, clear the dirty bits.  Previously they were left indicating
the cache was dirty. This led to confusion about whether there really
was dirty data in the cache or not.  (This was a harmless bug.)

Reported-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Signed-off-by: Joe Thornber &lt;ejt@redhat.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Alasdair G Kergon &lt;agk@redhat.com&gt;
</content>
</entry>
<entry>
<title>dm cache: avoid calling policy destructor twice on error</title>
<updated>2013-03-20T17:21:26Z</updated>
<author>
<name>Heinz Mauelshagen</name>
<email>heinzm@redhat.com</email>
</author>
<published>2013-03-20T17:21:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b978440b8db901aba0c4cd38c7c841c9b5cd9a7e'/>
<id>urn:sha1:b978440b8db901aba0c4cd38c7c841c9b5cd9a7e</id>
<content type='text'>
If the cache policy's config values are not able to be set we must
set the policy to NULL after destroying it in create_cache_policy()
so we don't attempt to destroy it a second time later.

Signed-off-by: Heinz Mauelshagen &lt;heinzm@redhat.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Alasdair G Kergon &lt;agk@redhat.com&gt;
</content>
</entry>
<entry>
<title>dm cache: detect cache_create failure</title>
<updated>2013-03-20T17:21:26Z</updated>
<author>
<name>Heinz Mauelshagen</name>
<email>heinzm@redhat.com</email>
</author>
<published>2013-03-20T17:21:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=617a0b89da4898d4cc990c9eb4bc9c0591c538a5'/>
<id>urn:sha1:617a0b89da4898d4cc990c9eb4bc9c0591c538a5</id>
<content type='text'>
Return error if cache_create() fails.

A missing return check made cache_ctr continue even after an error in
cache_create() resulting in the cache object being destroyed.  So a
simple failure like an odd number of cache policy config value arguments
would result in an oops.

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