Re: [PATCH] dm cache: fix race affecting dirty block count

From: Pranith Kumar
Date: Sun Aug 03 2014 - 01:29:10 EST


On Sun, Aug 3, 2014 at 1:17 AM, Pranith Kumar <bobby.prani@xxxxxxxxx> wrote:
> On 08/03/2014 12:57 AM, Pranith Kumar wrote:
>> On 08/03/2014 12:46 AM, Pranith Kumar wrote:
>>> 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@xxxxxxxxx> 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
>>
>

Bah, please ignore all the previous patches about pointers. It is me
who is drunk and got my pointers mixed up. :(

--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/