Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932669AbbHJStz (ORCPT ); Mon, 10 Aug 2015 14:49:55 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:45402 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932162AbbHJSty (ORCPT ); Mon, 10 Aug 2015 14:49:54 -0400 Date: Mon, 10 Aug 2015 11:49:53 -0700 From: "gregkh@linuxfoundation.org" To: Leonid Yegoshin Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Markos Chandras , linux-mips@linux-mips.org, Ralf Baechle Subject: Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores Message-ID: <20150810184953.GA19646@kroah.com> References: <20150808220718.304261727@linuxfoundation.org> <55C8EF32.5010807@imgtec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C8EF32.5010807@imgtec.com> User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3165 Lines: 83 On Mon, Aug 10, 2015 at 11:36:34AM -0700, Leonid Yegoshin wrote: > On 08/08/2015 03:08 PM, gregkh@linuxfoundation.org wrote: > >4.1-stable review patch. If anyone has any objections, please let me know. > > > > > Yes, I have objection. Please look into excepts from my mail exchange with > Markos: > > >On 06/25/2015 03:59 AM, Markos Chandras wrote: > > > >>@@ -51,9 +51,8 @@ static inline void r4k_on_each_cpu(void (*func) (void *info), void *info) > >> { > >> preempt_disable(); > >>-#ifndef CONFIG_MIPS_MT_SMP > >>- smp_call_function(func, info, 1); > >>-#endif > >>+ if (config_enabled(CONFIG_SMP)) > >>+ smp_call_function_many(&cpu_foreign_map, func, info, 1); > >> func(info); > >> preempt_enable(); > >> } > > > >You can NOT do this because r4k_on_each_cpu() is still used for > >non-MIPS/IMG processors for SAFE INDEX cache flushes - > >cpu_has_safe_index_cacheops (it is not safe in CM/CM2/CM3 environment). > > > > > >And a little explanation and history: > > > >The function r4k_on_each_cpu() can NOT be used simultaneously for index > >cacheops and address cacheops because both have a different rules in > >applying in other cores and that is different in inter-core HW blocks of > >various vendors. CM propogates address cacheops from core-to-core (no IPI > >calls are needed) but another vendors may do not - this is indicated by > >CONFIG_MIPS_MT_SMP (and a dropped now CONFIG_MIPS_MT_SMTC). > > > >Unfortunately, before 2.6.35.9 this function was used for index cacheops > >too in any kernel and that is WRONG, at least for CM-based systems. > >So, I splitted index and address cacheops and wrote a functions > >r4k_indexop_on_each_cpu and put it in use in at least in dlm-2.6.35.9 and > >it finally made a way to dev-linux-mti-3.6. This is a famous patch named: > > > > MIPS: Cache flush functions are reworked. > > > > This patch is a preparation for EVA support in kernel. > > > > However, it also fixes a bug then index cacheop was not ran > > on multiple CPUs with unsafe index cacheops (flush_cache_vmap, > > flush_icache_range, flush_cache_range, __flush_cache_all). > > > > Additionally, it optimizes a usage of index and address cacheops for > > address range flushes depending from address range size. > > > > Because of that reasons it is a separate patch from EVA support. > > > > Signed-off-by: Leonid Yegoshin > > Signed-off-by: Steven J. Hill > > (cherry picked from commit 6b05dd71da1136fbad0ce642790c4c99343f05e7) > > > > (history is skipped) > > Note: the replacement of > > if (config_enabled(CONFIG_SMP)) > > to > if (!mips_cm_present()) > > doesn't solve a problem - in CM-based environment the index cache ops MUST > be delivered to other core via IPI. So, this is broken in Linus's tree too? Or is it fixed there, and if so, what is the git commit id? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/