From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751975AbcF0Ic6 (ORCPT ); Mon, 27 Jun 2016 04:32:58 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:55562 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751639AbcF0Ic5 (ORCPT ); Mon, 27 Jun 2016 04:32:57 -0400 Date: Mon, 27 Jun 2016 10:32:54 +0200 From: Pavel Machek To: Jiri Kosina Cc: Torsten Duwe , matz@suse.de, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Disable non-ABI-compliant optimisations for live patching Message-ID: <20160627083254.GB24334@amd> References: <20160622142441.GA31609@lst.de> <20160626223720.GC21026@amd> <20160627082119.GA24334@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 2016-06-27 10:26:58, Jiri Kosina wrote: > On Mon, 27 Jun 2016, Pavel Machek wrote: > > > > > I thought that in such case, person creating the live patch should > > > > notice and adjust patch appropriately, at assembly level if > > > > neccessary..? > > > > > > Yes, that still holds; a lot of things could be automated though, and > > > creating the automation tools is one of the big TODO items. > > > > So the patch is not a bugfix, it is just something that slows down > > kernel to make stuff easier for the person doing the live patching...? > > Well, up to the last week noone realized the implications IPA-RA has for > live patches. Now that we know about this, we have to deal with it > somehow; as currently gcc doesn't provide easy way for us to obtain the > information (non-existing -fdump-ipa-ra), disabling the optimization on > CONFIG_LIVEPATCH-enabled kernels is a sensible workaround before we're > able to get the information from gcc. You can still build the whole kernel with the patch applied, and look for code differences in all the functions, then analyzing them... no? > > What you actually want is "whenever source of function A influenced code > > in function B, I want to be notified", right? > > > > If gcc can eliminate an if() brach in function B, because it can tell > > reading function A it can not happen, you need to know. Maybe that's > > limited to ABI today, but... > > Yeah; dead code elimination is also a thing to watch for. That was supposed to be just an example. I believe you want "whenever source of function A influenced code in function B, I want to be notified", and I believe it should be documented as such. gcc might produce new and interesting optimalizations in future. I believe you want --dont-let-function-influence-function switch to gcc, not growing list of --no-optimalization-A, --no-optimalization-B... Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html