From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751790AbbKPV7e (ORCPT ); Mon, 16 Nov 2015 16:59:34 -0500 Received: from mx2.suse.de ([195.135.220.15]:41478 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750778AbbKPV7b (ORCPT ); Mon, 16 Nov 2015 16:59:31 -0500 Date: Mon, 16 Nov 2015 22:59:30 +0100 (CET) From: Jiri Kosina X-X-Sender: jkosina@pobox.suse.cz To: Chris J Arges cc: live-patching@vger.kernel.org, jpoimboe@redhat.com, sjenning@redhat.com, Vojtech Pavlik , pmladek@suse.com, jeyu@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3 v7] livepatch: add old_sympos as disambiguator field to klp_func In-Reply-To: <1447693391-10065-2-git-send-email-chris.j.arges@canonical.com> Message-ID: References: <1447431804-18786-1-git-send-email-chris.j.arges@canonical.com> <1447693391-10065-1-git-send-email-chris.j.arges@canonical.com> <1447693391-10065-2-git-send-email-chris.j.arges@canonical.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 Mon, 16 Nov 2015, Chris J Arges wrote: > In cases of duplicate symbols, old_sympos will be used to disambiguate > instead of old_addr. By default old_sympos will be 0, and patching will > only succeed if the symbol is unique. Specifying a positive value will > ensure that occurrence of the symbol in kallsyms for the patched object > will be used for patching if it is valid. > > In addition, make old_addr an internal structure field not to be specified > by the user. Finally, remove klp_find_verify_func_addr as it can be > replaced by klp_find_object_symbol directly. > > Support for symbol position disambiguation for relocations is added in the > next patch in this series. Chris, I am sorry to repeat myself, but the changelog is quite verbose with respect to "what is being done", but it doesn't contain any information whatsoever with respect to "why is this an improvement over current state", IOW why we are changing the status quo at all. This absolutely has to be present in the changelog. Thanks, -- Jiri Kosina SUSE Labs