Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp895033yba; Wed, 24 Apr 2019 11:20:43 -0700 (PDT) X-Google-Smtp-Source: APXvYqzFqaBF6idtCLjf4wuNyZCXBDtnDLCvwhWBEr22KhGDgcBEiZxCTB11ebRNvjHJIw7dxv09 X-Received: by 2002:a62:1b8a:: with SMTP id b132mr34547379pfb.19.1556130043692; Wed, 24 Apr 2019 11:20:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556130043; cv=none; d=google.com; s=arc-20160816; b=ESXLCOETyo0/RvOdn2JwoB/heAgwXWvmZe7NygnYkMLDoRx1s5lRcsLQ6krQ9Gb7TV 0x3pjslVvC5BEpJxLvxH2tz7WwFe/+cZjCuWyvVyV4Se4p8wiiOIogXs/CQa+Qy5hUXG igB748seILZTdDBwyWXJy05l4GkHXuG5PXmr27RTvdR8+pDW0Ub1EzoIoCiuY/1CuW7H B61wmss48v8DK0ySMwTHGxqC5r3My/R2TgD5SlvLT1l1O2b3MKTzAacRdnC07hoPNM8t z66NtAMYoK20LvcwJH5TZsh/MOGM7llclInljtQjIW+/1g/vIimXAVN/pgaiI6Q2OOmy 4S6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=9r7NwCafTZpHa90jNb2wrUhbHw0WgRk+RmvXfVqw4GQ=; b=hoyDOAG8T41d1lbr9wcRlJcYf18DWQ2XQho5wppqy9R1VC67mlonBTFEae04WeLT45 yJVeyweg0WCldvPShcT65wUITwA6ioTMRBtE7oX9fLRdVQ50tVbsFfi+3+9wGbyP9aPS yN2F0ESeEbQPVnSIL+hb68hmaZfEHGh97QqGmHo7Dk1f2k3rTBPHDgOQB/uAix146fLv nE3LULBC2IQLJiHzjReRb85tmchYmf7bleywgjebP3iZ32mfSK8PkVTdRqPMfzQF82Sw CRMUIF0tC/lFyvC2KWNIR6KefyI1KXAHgxWmHrM6YWe0Mra5AoFs767OZWz9OXQ3x6OI 7IwQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q5si18436049pga.498.2019.04.24.11.20.28; Wed, 24 Apr 2019 11:20:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733260AbfDXSTL (ORCPT + 99 others); Wed, 24 Apr 2019 14:19:11 -0400 Received: from mx2.suse.de ([195.135.220.15]:51408 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731658AbfDXSTK (ORCPT ); Wed, 24 Apr 2019 14:19:10 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 650A9AEA1; Wed, 24 Apr 2019 18:19:08 +0000 (UTC) Date: Wed, 24 Apr 2019 20:19:07 +0200 (CEST) From: Miroslav Benes To: Joe Lawrence cc: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, linux-kbuild@vger.kernel.org, Jessica Yu , Jiri Kosina , Joao Moreira , Josh Poimboeuf , Konstantin Khlebnikov , Masahiro Yamada , Michael Matz , Nicolai Stange , Petr Mladek Subject: Re: [PATCH v3 0/9] klp-convert livepatch build tooling In-Reply-To: <20190417201316.GA690@redhat.com> Message-ID: References: <20190410155058.9437-1-joe.lawrence@redhat.com> <20190417201316.GA690@redhat.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [...] > Result: a small tweak to sympos_sanity_check() to relax its symbol > uniqueness verification: allow for duplicate > instances. Now it will only complain when a supplied symbol references > the same but a different . > > diff --git a/scripts/livepatch/klp-convert.c b/scripts/livepatch/klp-convert.c > index 82c27d219372..713835dfc9ec 100644 > --- a/scripts/livepatch/klp-convert.c > +++ b/scripts/livepatch/klp-convert.c > @@ -194,7 +194,10 @@ static void clear_sympos_annontations(struct elf *klp_elf) > } > } > > -/* Checks if two or more elements in usr_symbols have the same name */ > +/* > + * Checks if two or more elements in usr_symbols have the same > + * object and name, but different symbol position > + */ > static bool sympos_sanity_check(void) > { > bool sane = true; > @@ -203,7 +206,9 @@ static bool sympos_sanity_check(void) > list_for_each_entry(sp, &usr_symbols, list) { > aux = list_next_entry(sp, list); > list_for_each_entry_from(aux, &usr_symbols, list) { > - if (strcmp(sp->symbol_name, aux->symbol_name) == 0) { > + if (sp->pos != aux->pos && > + strcmp(sp->object_name, aux->object_name) == 0 && > + strcmp(sp->symbol_name, aux->symbol_name) == 0) > WARN("Conflicting KLP_SYMPOS definition: %s.%s,%d vs. %s.%s,%d.", > sp->object_name, sp->symbol_name, sp->pos, > aux->object_name, aux->symbol_name, aux->pos); Looks good and I'd definitely include it in v4. > Unique sympos > ------------- > > But even with the above workaround, specifying unique symbol positions > will (and should) result in a klp-convert complaint. > > When modifying the test module with unique symbol position annotation > values (1 and 2 respectively): > > test_klp_convert_multi_objs_a.c: > > extern void *state_show; > ... > KLP_MODULE_RELOC(vmlinux) vmlinux_relocs_b[] = { > KLP_SYMPOS(state_show, 1) > }; > > test_klp_convert_multi_objs_b.c: > > extern void *state_show; > ... > KLP_MODULE_RELOC(vmlinux) vmlinux_relocs_b[] = { > KLP_SYMPOS(state_show, 2) > }; > > > Each object file's symbol table contains a "state_show" instance: > > % eu-readelf --symbols lib/livepatch/test_klp_convert_multi_objs_a.o | grep '\' > 30: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UNDEF state_show > > % eu-readelf --symbols lib/livepatch/test_klp_convert_multi_objs_b.o | grep '\' > 20: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UNDEF state_show > > and the intermediate test_klp_convert_multi_objs.klp.o file contains a > combined .klp.module_relocs.vmlinux relocation section with two > KLP_SYMPOS structures, each with a unique value: > > % objcopy -O binary --only-section=.klp.module_relocs.vmlinux \ > lib/livepatch/test_klp_convert_multi_objs.klp.o >(hexdump) > > 0000000 0000 0000 0000 0000 0001 0000 0000 0000 > 0000010 0000 0000 0002 0000 > > but the symbol tables were merged, sorted and non-unique symbols > removed, leaving a *single* unresolved "state_show" instance: > > % eu-readelf --symbols lib/livepatch/test_klp_convert_multi_objs.klp.o | grep '\' > 53: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UNDEF state_show > > which means that even though we have separate relocations for each > "state_show" instance: > > Relocation section [ 6] '.rela.text.unlikely' for section [ 5] '.text.unlikely' at offset 0x44510 contains 11 entries: > Offset Type Value Addend Name > 0x0000000000000003 X86_64_32S 000000000000000000 +0 state_show > ... > 0x0000000000000034 X86_64_32S 000000000000000000 +0 state_show > ... > > they share the same rela->sym and there is no way to distinguish which > one correlates to which KLP_SYMPOS structure. > > > Future Work > ----------- > > I don't see an easy way to support multiple homonym > symbols with unique values in the current livepatch module > Elf format. The only solutions that come to mind right now include > renaming homonym symbols somehow to retain the relocation->symbol > relationship when separate object files are combined. Perhaps an > intermediate linker step could make annotated symbols unique in some way > to achieve this. /thinking out loud I'd set this aside for now and we can return to it later. I think it could be quite rare in practice. I was thinking about renaming the symbol too. We can extend the symbol naming convention we have now and deal with it in klp_resolve_symbols(), but maybe Josh will come up with something clever and cleaner. Miroslav