From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Simek Subject: Re: [PATCH 07/56] microblaze_v2: Signal support Date: Tue, 06 May 2008 11:41:15 +0200 Message-ID: <482027BB.3090705@monstr.eu> References: <9a7c6646e5dd9724c1cf34767adec181481fa3ef.1209897266.git.monstr@monstr.eu> <20080505213244.8DC757A0084@mail70-wa4.bigfish.com> <1210030436.5798.148.camel@localhost> <20080506001339.619971A58057@mail55-wa4.bigfish.com> <1210033550.5798.185.camel@localhost> <20080506003341.AFA5911E804F@mail138-va3.bigfish.com> Reply-To: monstr@seznam.cz Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from smtp1.wifiinternet.cz ([89.31.47.1]:64630 "EHLO bor.wifiinternet.cz" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1761199AbYEFJk0 (ORCPT ); Tue, 6 May 2008 05:40:26 -0400 In-Reply-To: <20080506003341.AFA5911E804F@mail138-va3.bigfish.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Stephen Neuendorffer Cc: John Williams , monstr@seznam.cz, linux-kernel@vger.kernel.org, arnd@arndb.de, linux-arch@vger.kernel.org, John Linn , matthew@wil.cx, will.newton@gmail.com, drepper@redhat.com, microblaze-uclinux@itee.uq.edu.au, grant.likely@secretlab.ca I hope that conclusion is remove #if 0 from signal.c code. M > You're right. (I think I've been staring at this too much today... :) > > Steve > >> -----Original Message----- >> From: John Williams [mailto:john.williams@petalogix.com] >> Sent: Monday, May 05, 2008 5:26 PM >> To: Stephen Neuendorffer >> Cc: monstr@seznam.cz; linux-kernel@vger.kernel.org; arnd@arndb.de; > linux-arch@vger.kernel.org; John >> Linn; matthew@wil.cx; will.newton@gmail.com; drepper@redhat.com; > microblaze-uclinux@itee.uq.edu.au; >> grant.likely@secretlab.ca; Michal Simek >> Subject: RE: [PATCH 07/56] microblaze_v2: Signal support >> >> On Mon, 2008-05-05 at 17:13 -0700, Stephen Neuendorffer wrote: >>> I'm somewhat ignorant about what this code is attempting to do, but > with >>> some quick poking around (m68knommu, blackfin) seems to suggest that >>> other architectures don't do this, while others (v850) have almost >>> exactly the same code (although they are somewhat smarter and are >>> careful not to flush the whole cache). >>> >>> At the very least, it seems like there is some work in this area > needed. >> flush_cache_sigtramp should just invalidate 8 bytes up from the base >> address of the trampoline. This is just the region on the process > stack >> where we insert a kind of call-back back. Writing the opcodes goes > via >> the dcache, and so there's a vanishingly small possibility that the > CPU >> will get a false hit on on an icache fetch when the code is executed. >> >> That was what Michal's patch had when I scanned it yesterday. It >> certainly won't/shouldn't be invalidating the entire cache. >> >> Cheers, >> >> John >> >> > > > >