On Tue, Feb 25, 2014 at 9:45 AM, Josh Boyer <jwbo...@fedoraproject.org> wrote:
> On Thu, Feb 13, 2014 at 4:49 PM, Sander Eikelenboom
> <li...@eikelenboom.it> wrote:
>>
>> Thursday, February 13, 2014, 9:14:47 PM, you wrote:
>>
>>> On Tue, 2014-02-11 at 20:17 -0800, Eric Dumazet wrote:
>>>> On Tue, 2014-02-11 at 18:07 -0800, Dan Williams wrote:
>>>>
>>>> > The overlap granularity is too large. Multiple dma_map_single
>>>> > mappings are allowed to a given page as long as they don't collide on
>>>> > the same cache line.
>>>> >
>>>>
>>>> I am not sure why you try number of mappings of a page.
>>>>
>>>> Try launching 100 concurrent netperf -t TCP_SENFILE
>>>>
>>>> Same page might be mapped more than 100 times, more than 10000 times in
>>>> some cases.
>>
>>> Thanks for that test case.
>>
>>> I updated the fix patch with the following.
>>
>>> diff --git a/lib/dma-debug.c b/lib/dma-debug.c
>>> index 42b12740940b..611010df1e9c 100644
>>> --- a/lib/dma-debug.c
>>> +++ b/lib/dma-debug.c
>>> @@ -513,6 +513,13 @@ static int active_cln_insert(struct dma_debug_entry
>>> *entry)
>>> unsigned long flags;
>>> int rc;
>>>
>>> + /* If the device is not writing memory then we don't have any
>>> + * concerns about the cpu consuming stale data. This mitigates
>>> + * legitimate usages of overlapping mappings.
>>> + */
>> + if (entry->>direction == DMA_TO_DEVICE)
>>> + return 0;
>>> +
>>> spin_lock_irqsave(&radix_lock, flags);
>>> rc = radix_tree_insert(&dma_active_cacheline, to_cln(entry), entry);
>>> if (rc == -EEXIST)
>>> @@ -526,6 +533,10 @@ static void active_cln_remove(struct dma_debug_entry
>>> *entry)
>>> {
>>> unsigned long flags;
>>>
>>> + /* ...mirror the insert case */
>> + if (entry->>direction == DMA_TO_DEVICE)
>>> + return;
>>> +
>>> spin_lock_irqsave(&radix_lock, flags);
>>> /* since we are counting overlaps the final put of the
>>> * cacheline will occur when the overlap count is 0.
>>
>>
>>> Sander, barring a negative test result from you I'll send the attached
>>> patch to Andrew.
>>
>> Hi Dan,
>>
>> That seems to effectively suppress the warning, thanks and:
>>
>> Tested-by; Sander Eikelenboom <li...@eikelenboom.it>
>
> Is there a reason this isn't in Linus' tree yet?
>
It's in -mm and now -next, I expect it will go upstream with akpm's next sync.
--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
