<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/md/bcache/bcache.h, branch linux-4.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.9.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.9.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2020-10-01T18:40:03Z</updated>
<entry>
<title>bcache: fix a lost wake-up problem caused by mca_cannibalize_lock</title>
<updated>2020-10-01T18:40:03Z</updated>
<author>
<name>Guoju Fang</name>
</author>
<published>2019-11-13T08:03:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fa12d56b8d17410418e86aaea70ba82f96df2548'/>
<id>urn:sha1:fa12d56b8d17410418e86aaea70ba82f96df2548</id>
<content type='text'>
[ Upstream commit 34cf78bf34d48dddddfeeadb44f9841d7864997a ]

This patch fix a lost wake-up problem caused by the race between
mca_cannibalize_lock and bch_cannibalize_unlock.

Consider two processes, A and B. Process A is executing
mca_cannibalize_lock, while process B takes c-&gt;btree_cache_alloc_lock
and is executing bch_cannibalize_unlock. The problem happens that after
process A executes cmpxchg and will execute prepare_to_wait. In this
timeslice process B executes wake_up, but after that process A executes
prepare_to_wait and set the state to TASK_INTERRUPTIBLE. Then process A
goes to sleep but no one will wake up it. This problem may cause bcache
device to dead.

Signed-off-by: Guoju Fang &lt;fangguoju@gmail.com&gt;
Signed-off-by: Coly Li &lt;colyli@suse.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bcache: fix for data collapse after re-attaching an attached device</title>
<updated>2018-05-30T05:50:25Z</updated>
<author>
<name>Tang Junhui</name>
</author>
<published>2018-02-07T19:41:46Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0d5da3123946e74d822022f95091fc3fe60f9f61'/>
<id>urn:sha1:0d5da3123946e74d822022f95091fc3fe60f9f61</id>
<content type='text'>
[ Upstream commit 73ac105be390c1de42a2f21643c9778a5e002930 ]

back-end device sdm has already attached a cache_set with ID
f67ebe1f-f8bc-4d73-bfe5-9dc88607f119, then try to attach with
another cache set, and it returns with an error:
[root]# cd /sys/block/sdm/bcache
[root]# echo 5ccd0a63-148e-48b8-afa2-aca9cbd6279f &gt; attach
-bash: echo: write error: Invalid argument

After that, execute a command to modify the label of bcache
device:
[root]# echo data_disk1 &gt; label

Then we reboot the system, when the system power on, the back-end
device can not attach to cache_set, a messages show in the log:
Feb  5 12:05:52 ceph152 kernel: [922385.508498] bcache:
bch_cached_dev_attach() couldn't find uuid for sdm in set

In sysfs_attach(), dc-&gt;sb.set_uuid was assigned to the value
which input through sysfs, no matter whether it is success
or not in bch_cached_dev_attach(). For example, If the back-end
device has already attached to an cache set, bch_cached_dev_attach()
would fail, but dc-&gt;sb.set_uuid was changed. Then modify the
label of bcache device, it will call bch_write_bdev_super(),
which would write the dc-&gt;sb.set_uuid to the super block, so we
record a wrong cache set ID in the super block, after the system
reboot, the cache set couldn't find the uuid of the back-end
device, so the bcache device couldn't exist and use any more.

In this patch, we don't assigned cache set ID to dc-&gt;sb.set_uuid
in sysfs_attach() directly, but input it into bch_cached_dev_attach(),
and assigned dc-&gt;sb.set_uuid to the cache set ID after the back-end
device attached to the cache set successful.

Signed-off-by: Tang Junhui &lt;tang.junhui@zte.com.cn&gt;
Reviewed-by: Michael Lyle &lt;mlyle@lyle.org&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>bcache: fix for gc and write-back race</title>
<updated>2017-09-27T12:39:25Z</updated>
<author>
<name>Tang Junhui</name>
</author>
<published>2017-09-06T06:25:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=57aa1a6967b28431d62beec299125a969a469f3f'/>
<id>urn:sha1:57aa1a6967b28431d62beec299125a969a469f3f</id>
<content type='text'>
commit 9baf30972b5568d8b5bc8b3c46a6ec5b58100463 upstream.

gc and write-back get raced (see the email "bcache get stucked" I sended
before):
gc thread                               write-back thread
|                                       |bch_writeback_thread()
|bch_gc_thread()                        |
|                                       |==&gt;read_dirty()
|==&gt;bch_btree_gc()                      |
|==&gt;btree_root() //get btree root       |
|                //node write locker    |
|==&gt;bch_btree_gc_root()                 |
|                                       |==&gt;read_dirty_submit()
|                                       |==&gt;write_dirty()
|                                       |==&gt;continue_at(cl,
|                                       |               write_dirty_finish,
|                                       |               system_wq);
|                                       |==&gt;write_dirty_finish()//excute
|                                       |               //in system_wq
|                                       |==&gt;bch_btree_insert()
|                                       |==&gt;bch_btree_map_leaf_nodes()
|                                       |==&gt;__bch_btree_map_nodes()
|                                       |==&gt;btree_root //try to get btree
|                                       |              //root node read
|                                       |              //lock
|                                       |-----stuck here
|==&gt;bch_btree_set_root()
|==&gt;bch_journal_meta()
|==&gt;bch_journal()
|==&gt;journal_try_write()
|==&gt;journal_write_unlocked() //journal_full(&amp;c-&gt;journal)
|                            //condition satisfied
|==&gt;continue_at(cl, journal_write, system_wq); //try to excute
|                               //journal_write in system_wq
|                               //but work queue is excuting
|                               //write_dirty_finish()
|==&gt;closure_sync(); //wait journal_write execute
|                   //over and wake up gc,
|-------------stuck here
|==&gt;release root node write locker

This patch alloc a separate work-queue for write-back thread to avoid such
race.

(Commit log re-organized by Coly Li to pass checkpatch.pl checking)

Signed-off-by: Tang Junhui &lt;tang.junhui@zte.com.cn&gt;
Acked-by: Coly Li &lt;colyli@suse.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>bcache: Make gc wakeup sane, remove set_task_state()</title>
<updated>2017-02-23T16:44:36Z</updated>
<author>
<name>Kent Overstreet</name>
</author>
<published>2016-10-27T03:31:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8629aed2387cd22d1bde76e798034c3ea31018f7'/>
<id>urn:sha1:8629aed2387cd22d1bde76e798034c3ea31018f7</id>
<content type='text'>
commit be628be09563f8f6e81929efbd7cf3f45c344416 upstream.

Signed-off-by: Kent Overstreet &lt;kent.overstreet@gmail.com&gt;
Cc: Coly Li &lt;colyli@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>bcache: remove driver private bio splitting code</title>
<updated>2015-08-13T18:31:40Z</updated>
<author>
<name>Kent Overstreet</name>
</author>
<published>2013-11-24T07:11:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=749b61dab30736eb95b1ee23738cae90973d4fc3'/>
<id>urn:sha1:749b61dab30736eb95b1ee23738cae90973d4fc3</id>
<content type='text'>
The bcache driver has always accepted arbitrarily large bios and split
them internally.  Now that every driver must accept arbitrarily large
bios this code isn't nessecary anymore.

Cc: linux-bcache@vger.kernel.org
Signed-off-by: Kent Overstreet &lt;kent.overstreet@gmail.com&gt;
[dpark: add more description in commit message]
Signed-off-by: Dongsu Park &lt;dpark@posteo.net&gt;
Signed-off-by: Ming Lin &lt;ming.l@ssi.samsung.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
</content>
</entry>
<entry>
<title>bcache: fix crash with incomplete cache set</title>
<updated>2014-08-04T22:23:04Z</updated>
<author>
<name>Slava Pestov</name>
</author>
<published>2014-07-11T19:17:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bf0c55c986540483c34ca640f2eef4c3314388b1'/>
<id>urn:sha1:bf0c55c986540483c34ca640f2eef4c3314388b1</id>
<content type='text'>
Change-Id: I6abde52afe917633480caaf4e2518f42a816d886
</content>
</entry>
<entry>
<title>arch: Mass conversion of smp_mb__*()</title>
<updated>2014-04-18T12:20:48Z</updated>
<author>
<name>Peter Zijlstra</name>
</author>
<published>2014-03-17T17:06:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4e857c58efeb99393cba5a5d0d8ec7117183137c'/>
<id>urn:sha1:4e857c58efeb99393cba5a5d0d8ec7117183137c</id>
<content type='text'>
Mostly scripted conversion of the smp_mb__* barriers.

Signed-off-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Acked-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Link: http://lkml.kernel.org/n/tip-55dhyhocezdw1dg7u19hmh1u@git.kernel.org
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: linux-arch@vger.kernel.org
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>bcache: Kill bucket-&gt;gc_gen</title>
<updated>2014-03-18T19:24:54Z</updated>
<author>
<name>Kent Overstreet</name>
</author>
<published>2014-02-28T01:51:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3a2fd9d5090b83aab85378a846fa10f39b0b5aa7'/>
<id>urn:sha1:3a2fd9d5090b83aab85378a846fa10f39b0b5aa7</id>
<content type='text'>
gc_gen was a temporary used to recalculate last_gc, but since we only need
bucket-&gt;last_gc when gc isn't running (gc_mark_valid = 1), we can just update
last_gc directly.

Signed-off-by: Kent Overstreet &lt;kmo@daterainc.com&gt;
</content>
</entry>
<entry>
<title>bcache: Kill unused freelist</title>
<updated>2014-03-18T19:23:36Z</updated>
<author>
<name>Kent Overstreet</name>
</author>
<published>2014-03-17T23:55:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2531d9ee61fa08a5a9ab8f002c50779888d232c7'/>
<id>urn:sha1:2531d9ee61fa08a5a9ab8f002c50779888d232c7</id>
<content type='text'>
This was originally added as at optimization that for various reasons isn't
needed anymore, but it does add a lot of nasty corner cases (and it was
responsible for some recently fixed bugs). Just get rid of it now.

Signed-off-by: Kent Overstreet &lt;kmo@daterainc.com&gt;
</content>
</entry>
<entry>
<title>bcache: Rework btree cache reserve handling</title>
<updated>2014-03-18T19:23:35Z</updated>
<author>
<name>Kent Overstreet</name>
</author>
<published>2014-03-18T00:15:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0a63b66db566cffdf90182eb6e66fdd4d0479e63'/>
<id>urn:sha1:0a63b66db566cffdf90182eb6e66fdd4d0479e63</id>
<content type='text'>
This changes the bucket allocation reserves to use _real_ reserves - separate
freelists - instead of watermarks, which if nothing else makes the current code
saner to reason about and is going to be important in the future when we add
support for multiple btrees.

It also adds btree_check_reserve(), which checks (and locks) the reserves for
both bucket allocation and memory allocation for btree nodes; the old code just
kinda sorta assumed that since (e.g. for btree node splits) it had the root
locked and that meant no other threads could try to make use of the same
reserve; this technically should have been ok for memory allocation (we should
always have a reserve for memory allocation (the btree node cache is used as a
reserve and we preallocate it)), but multiple btrees will mean that locking the
root won't be sufficient anymore, and for the bucket allocation reserve it was
technically possible for the old code to deadlock.

Signed-off-by: Kent Overstreet &lt;kmo@daterainc.com&gt;
</content>
</entry>
</feed>
