From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161992AbbKEPSP (ORCPT ); Thu, 5 Nov 2015 10:18:15 -0500 Received: from mx2.suse.de ([195.135.220.15]:52266 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756303AbbKEPSN (ORCPT ); Thu, 5 Nov 2015 10:18:13 -0500 Date: Thu, 5 Nov 2015 16:18:12 +0100 (CET) From: Miroslav Benes To: Josh Poimboeuf cc: Chris J Arges , live-patching@vger.kernel.org, jeyu@redhat.com, Seth Jennings , Jiri Kosina , Vojtech Pavlik , linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] livepatch: old_name.number scheme in livepatch sysfs directory In-Reply-To: <20151104160354.GA29899@treble.redhat.com> Message-ID: References: <20151102203241.GF27488@treble.redhat.com> <1446505187-28970-1-git-send-email-chris.j.arges@canonical.com> <20151103145843.GH27488@treble.redhat.com> <20151103165058.GM27488@treble.redhat.com> <20151104160354.GA29899@treble.redhat.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 4 Nov 2015, Josh Poimboeuf wrote: > On Wed, Nov 04, 2015 at 10:52:52AM +0100, Miroslav Benes wrote: > > On Tue, 3 Nov 2015, Josh Poimboeuf wrote: > > > > Object entry would be empty for not loaded object. I would not > > > > dare to propose to remove such object entries. It would make things worse. > > > > > > Why would removing an empty object entry make things worse? > > > > I think it all comes down to a question whether the sysfs entries say what > > a patch is capable to patch or what this patch is currently patching in > > the system. I am inclined to the former so the removal would make me > > nervous. But I am not against the second approach. We are still in testing > > mode as far as sysfs is concerned so we can try even harsh changes and see > > how it's gonna go. > > I see your point. This approach only describes what is patched now, but > it doesn't describe what *will* be patched. Ideally we could find a way > to describe both. > > Speaking of harsh changes, here's an idea. Which is the very same you proposed last year when I tried to persuade you to get rid off old_addr and stuff. I called it crazy I remember :D. So here we are again... > What if we require the patch author to supply the value of 'n' instead > of supplying the symbol address? We could get rid of 'old_addr' as an > input in klp_func and and replace it with 'old_sympos' which has the > value of 'n'. Or alternatively we could require old_name to be of the > format "func,n". > > That would uniquely identify each patched function, even _before_ the > object is loaded. I find it reasonable and we should try it. I think that old_sympos should have this semantics 0 - default, preserve more or less current behaviour. If the symbol is unique there is no problem. If it is not the patching would fail. 1, 2, ... - occurrence of the symbol in kallsyms. The advantage is that if the user does not care and is certain that the symbol is unique he doesn't have to do anything. If the symbol is not unique he still has means how to solve it. Does it make sense? > It would also fix another big problem we have today, where there's no > way to disambiguate duplicate symbols in modules, for both function > addresses and for relocs. True. > It would simplify the code in other places as well: no special handling > for kASLR, no need for klp_verify_vmlinux_symbol() vs > klp_find_object_symbol(). Which would be great. > A drawback is that it requires the patch author to do a little more due > diligence when filling out klp_func. But we already require them to be > careful. Yes, I don't think this should be a problem. > Thoughts? Yup, we should try it. I suppose that the order of the symbols in kallsyms table is stable for once-built kernel. It is the order of the symbols in the object files, isn't it? And since each livepatch module is built against the specific kernel there should be no issues with this. Regards, Miroslav