From: Pranith Kumar <bobby.prani@gmail.com>
To: anssi.hannula@iki.fi
Cc: ejt@redhat.com, snitzer@redhat.com,
LKML <linux-kernel@vger.kernel.org>,
torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] dm cache: fix race affecting dirty block count
Date: Sun, 03 Aug 2014 00:46:20 -0400 [thread overview]
Message-ID: <53DDBE9C.3030609@gmail.com> (raw)
In-Reply-To: <CAJhHMCCFz5qpxocMbF1POBbFs6zPVaoM_j-52bw5vwpm1MV9aw@mail.gmail.com>
On 08/02/2014 10:10 PM, Pranith Kumar wrote:
> Corrently adding Anssi this time.
>
> On Sat, Aug 2, 2014 at 10:00 PM, Pranith Kumar <bobby.prani@gmail.com> wrote:
>> Hello Anssi, Joe, Mike,
>>
>> I just found your patch in the latest rc and wanted to ask a few
>> questions. I am not sure how this patch helps at all other than luck in
>> that dm_cblock_t type is of type int32_t, which should guarantee that it
>> is atomic on most platforms. Which begs the question, what platform did
>> you encounter this problem?
>>
>> The patch purports to solve a race condition by making use of atomic_t.
>> I am not sure that is enough. If indeed there is a race you need to use
>> smp_mb__{before/after}_atomic() for both your uses of atomic_inc() and
>> atomic_set().
>>
>> Also I have a concern about why this mail was not CC'ed on LKML. I had
>> to go to some difficulty in finding this patch. So please CC LKML for
>> such patches.
>>
>> Thanks,
>> --
>> Pranith
>>
>> -- Begin forwarded Message --
>>
>>
>> nr_dirty is updated without locking, causing it to drift so that it is
>> non-zero (either a small positive integer, or a very large one when an
>> underflow occurs) even when there are no actual dirty blocks.
>>
>> Fix that by using an atomic type for nr_dirty.
>>
>> Signed-off-by: Anssi Hannula <anssi hannula iki fi>
>> Cc: Joe Thornber <ejt redhat com>
>> Cc: stable vger kernel org
Well, someone got their pointers mixed up. The following should help, but this is not enough if there are indeed concurrent accesses. Are you sure there are concurrent accesses?
diff --git a/drivers/md/dm-cache-target.c b/drivers/md/dm-cache-target.c
index 2c63326..d49ce45 100644
--- a/drivers/md/dm-cache-target.c
+++ b/drivers/md/dm-cache-target.c
@@ -1765,11 +1765,11 @@ static void destroy(struct cache *cache)
if (cache->wq)
destroy_workqueue(cache->wq);
- if (cache->dirty_bitset)
- free_bitset(cache->dirty_bitset);
+ if (cache.dirty_bitset)
+ free_bitset(cache.dirty_bitset);
- if (cache->discard_bitset)
- free_bitset(cache->discard_bitset);
+ if (cache.discard_bitset)
+ free_bitset(cache.discard_bitset);
if (cache->copier)
dm_kcopyd_client_destroy(cache->copier);
@@ -2269,15 +2269,15 @@ static int cache_create(struct cache_args *ca, struct cache **result)
r = -ENOMEM;
atomic_set(&cache->nr_dirty, 0);
- cache->dirty_bitset = alloc_bitset(from_cblock(cache->cache_size));
- if (!cache->dirty_bitset) {
+ cache.dirty_bitset = alloc_bitset(from_cblock(cache->cache_size));
+ if (!cache.dirty_bitset) {
*error = "could not allocate dirty bitset";
goto bad;
}
clear_bitset(cache->dirty_bitset, from_cblock(cache->cache_size));
cache->discard_nr_blocks = cache->origin_blocks;
- cache->discard_bitset = alloc_bitset(from_oblock(cache->discard_nr_blocks));
+ cache.discard_bitset = alloc_bitset(from_oblock(cache->discard_nr_blocks));
if (!cache->discard_bitset) {
*error = "could not allocate discard bitset";
goto bad;
next prev parent reply other threads:[~2014-08-03 4:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-03 2:00 [PATCH] dm cache: fix race affecting dirty block count Pranith Kumar
2014-08-03 2:08 ` Pranith Kumar
2014-08-03 2:10 ` Pranith Kumar
2014-08-03 3:33 ` Anssi Hannula
2014-08-03 4:01 ` Pranith Kumar
2014-08-04 10:48 ` Joe Thornber
2014-08-04 15:02 ` Pranith Kumar
2014-08-03 4:46 ` Pranith Kumar [this message]
2014-08-03 4:57 ` Pranith Kumar
2014-08-03 5:17 ` Pranith Kumar
2014-08-03 5:28 ` Pranith Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53DDBE9C.3030609@gmail.com \
--to=bobby.prani@gmail.com \
--cc=anssi.hannula@iki.fi \
--cc=ejt@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=snitzer@redhat.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).