From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailapp01.imgtec.com ([195.59.15.196]:2094 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753470AbbHDU65 (ORCPT ); Tue, 4 Aug 2015 16:58:57 -0400 Message-ID: <55C1278D.5090705@imgtec.com> Date: Tue, 4 Aug 2015 13:58:53 -0700 From: Leonid Yegoshin MIME-Version: 1.0 To: David Daney CC: David Daney , , , David Daney , Subject: Re: MIPS: Make set_pte() SMP safe. References: <1438649323-1082-1-git-send-email-ddaney.cavm@gmail.com> <55C10F4B.2050003@imgtec.com> <55C11A37.5070509@caviumnetworks.com> <55C1214F.8050208@imgtec.com> <55C1250B.2090508@caviumnetworks.com> In-Reply-To: <55C1250B.2090508@caviumnetworks.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: David, On 08/04/2015 01:48 PM, David Daney wrote: > I think the best way to think about it is to ignore vmap, and consider > the semantics of set_pte(). > ... > You can go around in circles all you want trying to indirectly avoid > using the buddy-PTE from another thread, but I think it is best to > make set_pte() have easily understood semantics (and semantics that > match those of other architectures) and not clobber things in > unexpected ways. My primary interest here is not a semantics of set_pte() but the followup of your finding, I tried test it: if guard page logic doesn't work anymore (as I can judge basing on your observations) then it calls back my old optimization in flush_cache_vmap(start, end) and similar. Right now it flushes the whole cache because if it tries to flush a guard page (and it THERE IS such attempt in some mm/*.c) it does TLB exception and I have a hard lock in do_page_fault(). Issue is significant for some GPU/display drivers which calls flushing VMALLOC area pretty often.