<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/md, branch v3.2.18</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/md?h=v3.2.18</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/md?h=v3.2.18'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2012-05-20T21:56:50Z</updated>
<entry>
<title>MD: Add del_timer_sync to mddev_suspend (fix nasty panic)</title>
<updated>2012-05-20T21:56:50Z</updated>
<author>
<name>Jonathan Brassow</name>
<email>jbrassow@redhat.com</email>
</author>
<published>2012-05-16T09:06:14Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ad87af4331c0b242788fbf668eefe2e311f2cd7f'/>
<id>urn:sha1:ad87af4331c0b242788fbf668eefe2e311f2cd7f</id>
<content type='text'>
commit 0d9f4f135eb6dea06bdcb7065b1e4ff78274a5e9 upstream.

Use del_timer_sync to remove timer before mddev_suspend finishes.

We don't want a timer going off after an mddev_suspend is called.  This is
especially true with device-mapper, since it can call the destructor function
immediately following a suspend.  This results in the removal (kfree) of the
structures upon which the timer depends - resulting in a very ugly panic.
Therefore, we add a del_timer_sync to mddev_suspend to prevent this.

Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>dm mpath: check if scsi_dh module already loaded before trying to load</title>
<updated>2012-05-20T21:56:42Z</updated>
<author>
<name>Mike Snitzer</name>
<email>snitzer@redhat.com</email>
</author>
<published>2012-05-12T00:43:21Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f6fa1ed89c2778e9755c9d1081bdb7cab38fbfb4'/>
<id>urn:sha1:f6fa1ed89c2778e9755c9d1081bdb7cab38fbfb4</id>
<content type='text'>
commit 510193a2d3d2e03ae53b95c0ae4f33cdff02cbf8 upstream.

If the requested scsi_dh module is already loaded then skip
request_module().

Multipath table loads can hang in an unnecessary __request_module.

Reported-by: Ben Marzinski &lt;bmarzins@redhat.com&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: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>md: fix possible corruption of array metadata on shutdown.</title>
<updated>2012-05-11T12:13:59Z</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.de</email>
</author>
<published>2012-04-24T00:23:16Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=31097a1c490c409385e28a64284bde16a4bfe76b'/>
<id>urn:sha1:31097a1c490c409385e28a64284bde16a4bfe76b</id>
<content type='text'>
commit 30b8aa9172dfeaac6d77897c67ee9f9fc574cdbb upstream.

commit c744a65c1e2d59acc54333ce8
  md: don't set md arrays to readonly on shutdown.

removed the possibility of a 'BUG' when data is written to an array
that has just been switched to read-only, but also introduced the
possibility that the array metadata could be corrupted.

If, when md_notify_reboot gets the mddev lock, the array is
in a state where it is assembled but hasn't been started (as can
happen if the personality module is not available, or in other unusual
situations), then incorrect metadata will be written out making it
impossible to re-assemble the array.

So only call __md_stop_writes() if the array has actually been
activated.

This patch is needed for any stable kernel which has had the above
commit applied.

Reported-by: Christoph Nelles &lt;evilazrael@evilazrael.de&gt;
Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>md/bitmap: prevent bitmap_daemon_work running while initialising bitmap</title>
<updated>2012-04-22T22:30:58Z</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.de</email>
</author>
<published>2012-04-12T06:05:06Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a629c2618e2a20298495c9b4f8a160d180486733'/>
<id>urn:sha1:a629c2618e2a20298495c9b4f8a160d180486733</id>
<content type='text'>
commit afbaa90b80b1ec66e5137cc3824746bfdf559b18 upstream.

If a bitmap is added while the array is active, it is possible
for bitmap_daemon_work to run while the bitmap is being
initialised.
This is particularly a problem if bitmap_daemon_work sees
bitmap-&gt;filemap as non-NULL before it has been filled in properly.
So hold bitmap_info.mutex while filling in -&gt;filemap
to prevent problems.

This patch is suitable for any -stable kernel, though it might not
apply cleanly before about 3.1.

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 thin: fix stacked bi_next usage</title>
<updated>2012-04-02T16:53:06Z</updated>
<author>
<name>Joe Thornber</name>
<email>ejt@redhat.com</email>
</author>
<published>2012-03-28T17:41:23Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=08c4bc38d68c073671068eb6fe54cbaa0a116b8c'/>
<id>urn:sha1:08c4bc38d68c073671068eb6fe54cbaa0a116b8c</id>
<content type='text'>
commit 6f94a4c45a6f744383f9f695dde019998db3df55 upstream.

Avoid using the bi_next field for the holder of a cell when deferring
bios because a stacked device below might change it.  Store the
holder in a new field in struct cell instead.

When a cell is created, the bio that triggered creation (the holder) was
added to the same bio list as subsequent bios.  In some cases we pass
this holder bio directly to devices underneath.  If those devices use
the bi_next field there will be trouble...

This also simplifies some code that had to work out which bio was the
holder.

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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dm persistent data: fix btree rebalancing after remove</title>
<updated>2012-04-02T16:53:05Z</updated>
<author>
<name>Joe Thornber</name>
<email>ejt@redhat.com</email>
</author>
<published>2012-03-28T17:41:23Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e9decde494c0960caaad20f6d5cd92d99a29dae2'/>
<id>urn:sha1:e9decde494c0960caaad20f6d5cd92d99a29dae2</id>
<content type='text'>
commit b0988900bae9ecf968a8a8d086a9eec671a9517a upstream.

When we remove an entry from a node we sometimes rebalance with it's
two neighbours.  This wasn't being done correctly; in some cases
entries have to move all the way from the right neighbour to the left
neighbour, or vice versa.  This patch pretty much re-writes the
balancing code to fix it.

This code is barely used currently; only when you delete a thin
device, and then only if you have hundreds of them in the same pool.
Once we have discard support, which removes mappings, this will be used
much more heavily.

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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dm exception store: fix init error path</title>
<updated>2012-04-02T16:53:05Z</updated>
<author>
<name>Andrei Warkentin</name>
<email>andrey.warkentin@gmail.com</email>
</author>
<published>2012-03-28T17:41:22Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e6958f1facf6b5369b6020a7b123a278407d25c5'/>
<id>urn:sha1:e6958f1facf6b5369b6020a7b123a278407d25c5</id>
<content type='text'>
commit aadbe266f2f89ccc68b52f4effc7b3a8b29521ef upstream.

Call the correct exit function on failure in dm_exception_store_init.

Signed-off-by: Andrei Warkentin &lt;andrey.warkentin@gmail.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 crypt: add missing error handling</title>
<updated>2012-04-02T16:53:05Z</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2012-03-28T17:41:22Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=33eb514c949a81198867cebfd34153f98d308b79'/>
<id>urn:sha1:33eb514c949a81198867cebfd34153f98d308b79</id>
<content type='text'>
commit 72c6e7afc43e19f68a31dea204fc366624d6eee9 upstream.

Always set io-&gt;error to -EIO when an error is detected in dm-crypt.

There were cases where an error code would be set only if we finish
processing the last sector. If there were other encryption operations in
flight, the error would be ignored and bio would be returned with
success as if no error happened.

This bug is present in kcryptd_crypt_write_convert, kcryptd_crypt_read_convert
and kcryptd_async_done.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Reviewed-by: Milan Broz &lt;mbroz@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 crypt: fix mempool deadlock</title>
<updated>2012-04-02T16:53:05Z</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2012-03-28T17:41:22Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=16c69b101a905588160514815f6285be4547f998'/>
<id>urn:sha1:16c69b101a905588160514815f6285be4547f998</id>
<content type='text'>
commit aeb2deae2660a1773c83d3c6e9e6575daa3855d6 upstream.

This patch fixes a possible deadlock in dm-crypt's mempool use.

Currently, dm-crypt reserves a mempool of MIN_BIO_PAGES reserved pages.
It allocates first MIN_BIO_PAGES with non-failing allocation (the allocation
cannot fail and waits until the mempool is refilled). Further pages are
allocated with different gfp flags that allow failing.

Because allocations may be done in parallel, this code can deadlock. Example:
There are two processes, each tries to allocate MIN_BIO_PAGES and the processes
run simultaneously.
It may end up in a situation where each process allocates (MIN_BIO_PAGES / 2)
pages. The mempool is exhausted. Each process waits for more pages to be freed
to the mempool, which never happens.

To avoid this deadlock scenario, this patch changes the code so that only
the first page is allocated with non-failing gfp mask. Allocation of further
pages may fail.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Milan Broz &lt;mbroz@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>md: fix clearing of the 'changed' flags for the bad blocks list.</title>
<updated>2012-04-02T16:52:46Z</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.de</email>
</author>
<published>2012-03-19T01:46:41Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b7715ffd670153926766a6b7419c306591f20676'/>
<id>urn:sha1:b7715ffd670153926766a6b7419c306591f20676</id>
<content type='text'>
commit d0962936bff659d20522555b517582a2715fd23f upstream.

In super_1_sync (the first hunk) we need to clear 'changed' before
checking read_seqretry(), otherwise we might race with other code
adding a bad block and so won't retry later.

In md_update_sb (the second hunk), in the case where there is no
metadata (neither persistent nor external), we treat any bad blocks as
an error.  However we need to clear the 'changed' flag before calling
md_ack_all_badblocks, else it won't do anything.

This patch is suitable for -stable release 3.0 and later.

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

</content>
</entry>
</feed>
