[Top] [All Lists]

Re: Regarding commit a16dad7 [MIPS: Fix potencial corruption]

To: Kevin Cernekee <>
Subject: Re: Regarding commit a16dad7 [MIPS: Fix potencial corruption]
From: Shmulik Ladkani <>
Date: Tue, 1 Jan 2013 13:29:05 +0200
Cc: Ralf Baechle <>,
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=ltC5HGHh5ze4QK6BcCyO+5cXUbETgTd3JXZJopn1HEY=; b=MKc35v3GnQw+7vn1IPmMaoeuzsc+TJj/AGsJTYVbZ5nmfUNp5Vapwcl6/sB56yS8gw lJRE9Bdiq6F9IKNKKeSLmH4ra+heaDtdWaGBAfMYfSATOeiXHNoIcTsWxvo0jJnf8sfh XbcgtWx1MHeNB3/N5kuDB1LKwzbMD2EWQ9bk1SH+w68sbpggepWyN9MZFu1DAq7gnbp4 DAJoHWbfSUo+9fHwujfkx+BRZfc8bP0xZduIWLr1BVmZ8Y9eg3vBEeS+gBgk0wfkiyKb 9iyq89rnYLFOtc9zOxLLJv2IT8QjJAa4AB25LnuYGXkuff5HRi40lWefnK8bln9V+K8f 347A==
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
References: <> <>
Hi Kevin,

On Tue, 1 Jan 2013 01:47:52 -0800 Kevin Cernekee <> wrote:
> On Tue, Jan 1, 2013 at 1:23 AM, Shmulik Ladkani
> <> wrote:
> > 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.
> There were a couple of USB drivers that stored DMA buffers inside a
> struct with other data, and invalidating the whole cacheline tended to
> clobber the other data.  For instance, intr_buff in
> drivers/net/usb/pegasus.h .

I see.

> Does CONFIG_DMA_API_DEBUG complain if it sees unaligned start
> addresses or sizes?  That would be a much nicer way of catching the
> problem, than troubleshooting random corruption.

Have no idea ;)
Hoping for Ralf to examine this.

I accidentally happened to notice an anomaly in the code: a revert was
executed (by Ralf Baechle in a16dad77), but it was incomplete:
(1) the comment was left, (2) revert wasn't executed on 'mips_sc_inv'.

Just pointing out the anomalies, for Ralf to acknowledge whether they
were deliberate or not.


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