linux-kernel - Re: [PATCH RESEND 1/6] MIPS: sync after cacheflush

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4D25EB30.4020905@pobox.com>
Date:	Fri, 07 Jan 2011 01:17:52 +0900
From:	Shinya Kuribayashi <skuribay@...ox.com>
To:	Kevin Cernekee <cernekee@...il.com>
CC:	Ralf Baechle <ralf@...ux-mips.org>, macro@...ux-mips.org,
	raiko@...si.msk.ru, linux-mips@...ux-mips.org,
	linux-kernel@...r.kernel.org, skuribay@...ox.com
Subject: Re: [PATCH RESEND 1/6] MIPS: sync after cacheflush

Hi,

sorry for my silence for several resending posts.  I talked with Ralf
on this briefly, when the patch was posted for the first time last
year.  He seems busy these days, so I'm trying to move things forward.

On 01/06/2011 04:31 PM, Kevin Cernekee wrote:
> On processors with deep write buffers, it is likely that many cycles
> will pass between a CACHE instruction and the time the data actually
> gets written out to DRAM.  Add a SYNC instruction to ensure that the
> buffers get emptied before the flush functions return.

Having a talk with appropriate people (probably including MIPS guys),
such CACHE behavior would be eventually considered to be _legitimate_,
Ralf said.  Thus we agree with this change required not only for BMIPS
cores, but also for the rest of processors, as one of cache features.

The problem is how to implement it.

Most of SYNC-equipped processors work fine without this treatment,
so unless it's required, we don't want to have __sync() after every
cacheflush operations.  Having SYNC there is somewhat waste of time.

> diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
> index b4923a7..dc5d9c4 100644
> --- a/arch/mips/mm/c-r4k.c
> +++ b/arch/mips/mm/c-r4k.c
> @@ -604,6 +604,7 @@ static void r4k_dma_cache_wback_inv(unsigned long addr, unsigned long size)
>  			r4k_blast_scache();
>  		else
>  			blast_scache_range(addr, addr + size);
> +		__sync();
>  		return;
>  	}
>  

Just random thought, how it's going to be when implementing this as,
- sort of barrier
- sort of hazard
- one of cache features (e.g., cpu_has_xxx or similar way)
- and so on...

Another concern is that, except for four __sync() insertions, are we
missing other places?

Ralf also thinks that run-time probe & detection would be better than
build-time configuration.  Optimization is easy and won't be problem
here, so we'd like to keep things synthesized as much as possible.

I couldn't imagine the final shape how this patch should be as of now,
sorry!

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