linux-mips
[Top] [All Lists]

Regarding commit a16dad7 [MIPS: Fix potencial corruption]

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Regarding commit a16dad7 [MIPS: Fix potencial corruption]
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Date: Tue, 1 Jan 2013 11:23:40 +0200
Cc: linux-mips@linux-mips.org, Kevin Cernekee <cernekee@gmail.com>, Shmulik Ladkani <shmulik.ladkani@gmail.com>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:mime-version :content-type:content-transfer-encoding; bh=KResWqwBYFV8OI+rN34d2Zyu16NSfjuhNhpYdMfilOc=; b=Z5VorQUmyend4B2yYshIFaJrtuVikHkVyi/7PTE+v1jxPdpz547uIQx/tr1AUAYFZQ Bm0+uoYlB1cX9l5HKWzIroRrs20Bq6sCigF48wUY27kAZC7CvINUHIAt5MYYjGSaOnTd 0OhB8C04hUDr8tPYpiWIhyCFV0YnKalGMpbB53cO61WPrYaUbeNuUs7odJ59d8DziF6m YxLu/Yt52e/Nzypp06RPEZDLpnTWORKLcxMSTAwG4wM3esa47k+Gi9pAEzNZpqPhgmAd X5HfGe76vf1Hsn8ZGW6B3Jum2s+Al6+t2mIyERnyBG9cWhtQ2XPHexWjikoEjx5ySoap +EQg==
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Sender: linux-mips-bounce@linux-mips.org
Hi,

Commit a16dad77 (MIPS: Fix potencial corruption) seems as a revert
of a8ca8b64 (MIPS: Avoid destructive invalidation on partial cachelines).

Snip of a16dad77:

@@ -643,9 +640,6 @@ static void r4k_dma_cache_inv(unsigned long addr, unsigned 
long size)
                         * hit ops with insufficient alignment.  Solved by
                         * aligning the address to cache line size.
                         */
-                       cache_op(Hit_Writeback_Inv_SD, addr & almask);
-                       cache_op(Hit_Writeback_Inv_SD,
-                                (addr + size - 1) & almask);


However,

(1)
The comment above the removed 'cache_op' instructions, which was
originally added as part of a8ca8b64, was not reverted, and now looks
out-of-context.

Any reason to keep the comment? If not, I'll submit a patch removing it.

(2)
Following a8ca8b64, another commit was submitted, adding similar
'cache_op' instructions to 'mips_sc_inv' - namely 96983ffe
(MIPS: MIPSxx SC: Avoid destructive invalidation on partial L2 cachelines).

Its purpose was to extend a8ca8b64, aligning behavior of 'mips_sc_inv'
to be similar to 'r4k_dma_cache_inv'.

Since the explicit 'cache_op' instrcutions are now removed from
'r4k_dma_cache_inv' (as of a16dad77), it probably makes sense to remove
them from 'mips_sc_inv' as well.

Any reason to keep these 'cache_op's? If not, I'll submit a patch.

Regards,
Shmulik

<Prev in Thread] Current Thread [Next in Thread>