Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp592170ybd; Wed, 26 Jun 2019 03:27:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqywlqL7ZH2qbj4bpRoEtCLOmtIyySzj4AwMx2HkdL4mwZQDyEnR6Xuk8eE3lvf9DEUJ4eYl X-Received: by 2002:a17:902:7c03:: with SMTP id x3mr4670482pll.242.1561544854927; Wed, 26 Jun 2019 03:27:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561544854; cv=none; d=google.com; s=arc-20160816; b=YVZwGU1FS7xoghohSx+1MmJPc9biTdfebCvscknJ20t3BcRUivPHwtkbCQC0xSFl// a+WrScHzLMqqAP+jq+OnaTG7cPJtu3VO2KlgdXF+lRTMCZKrSuzar2D/WeLvsZ7B+Ll6 1Dz0EGSCV3117m8vmF1Hw9gp/inp6D62N8MGiwUQHrLHmHXarTDp4sZz7eR17GBAOmOU ydj/Rh6AkpNiAklozi1gPb9NN9reK/tiOwuiiG5etbXOuaVzp+qyA/Nd7AQk3ffWDLyE +wZ2LMIFJ7mmIq/DmF5TXQUfmI9YjXKyGeAt9TVVF0MIkG/Dw68qo+RYQXi1uKZqNQ4O ZeoA== 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=sTR1/NHkBQBBeCnx4/gS+G9fslHINc4ai188re82pNo=; b=LCYT+Tjl8NbkLwy7MdTADtH8uIXXzkP3K6bhAezzBPLusajg9e7sgVwSUvYs3UgJ6F aF7T8W05ClvfvHVMNtDiytUHRVSMUgPC7ofY6cR/Dey15RTCAe+X8s5YWPlqUp8F5rRA fl0FtlG0QoVMI7R2I4R4j46maKuBydzK63iGEjuHwkEamo07JkGrDiKLBc1gzWFEyMrI Ca3ekl2abTCz6JHD00WOHjuQSiv2Ugc7xlUF9K9lfjDi2T8y1GhxoIEiDyLDHaBjO8ri AQFgvKDuo4Mxz5qGLkjXlAi4snU8BUJ1rKyfVZ4KwneLBpWSX2FvtRvkwX5Y04UrJRxY 3LQQ== 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 h32si3222676pld.402.2019.06.26.03.27.18; Wed, 26 Jun 2019 03:27:34 -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 S1726986AbfFZK1O (ORCPT + 99 others); Wed, 26 Jun 2019 06:27:14 -0400 Received: from mx2.suse.de ([195.135.220.15]:58260 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726131AbfFZK1O (ORCPT ); Wed, 26 Jun 2019 06:27:14 -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 3FC69AEEE; Wed, 26 Jun 2019 10:27:12 +0000 (UTC) Date: Wed, 26 Jun 2019 12:27:11 +0200 (CEST) From: Miroslav Benes To: Joe Lawrence cc: Petr Mladek , linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, linux-kbuild@vger.kernel.org Subject: Re: [PATCH v4 00/10] klp-convert livepatch build tooling In-Reply-To: <20190625190836.GL20356@redhat.com> Message-ID: References: <20190509143859.9050-1-joe.lawrence@redhat.com> <20190614083435.uq3mk6mprbatysol@pathway.suse.cz> <20190625190836.GL20356@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 On Tue, 25 Jun 2019, Joe Lawrence wrote: > On Tue, Jun 25, 2019 at 01:36:37PM +0200, Miroslav Benes wrote: > > > > [ ... snip ... ] > > > > If I revert commit d59cadc0a8f8 ("[squash] klp-convert: make > > convert_rela() list-safe") (from Joe's expanded github tree), the problem > > disappears. > > > > I haven't spotted any problem in the code and I cannot explain a > > dependency on GCC version. Any ideas? > > > > I can confirm that test_klp_convert1.ko crashes with RHEL-7 and its > older gcc. I added some debugging printf's to klp-convert and see: > > % ./scripts/livepatch/klp-convert \ > ./Symbols.list \ > lib/livepatch/test_klp_convert1.klp.o \ > lib/livepatch/test_klp_convert1.ko | \ > grep saved_command_line > > convert_rela: oldsec: .rela.text rela @ 0x1279670 rela->sym @ 0x12791f0 (.klp.sym.vmlinux.saved_command_line,0) offset: 0x3 > convert_rela: oldsec: .rela.text rela @ 0x1279cd0 rela->sym @ 0x12791f0 (.klp.sym.vmlinux.saved_command_line,0) offset: 0x9a > move_rela: rela @ 0x1279670 rela->sym @ 0x12791f0 (.klp.sym.vmlinux.saved_command_line,0) offset: 0x3 > main: skipping rela @ 0x1279cd0 rela->sym @ 0x12791f0 (.klp.sym.vmlinux.saved_command_line,0) (!must_convert) > > I think the problem is: > > - Relas at different offsets, but for the same symbol may share symbol > storage. Note the same rela->sym value above. > > - Before d59cadc0a8f8 ("[squash] klp-convert: make convert_rela() > list-safe"), convert_rela() iterated through the entire section's > relas, moving any of the same name. This was determined not to be > list safe when moving consecutive relas in the linked list. > > - After d59cadc0a8f8 ("[squash] klp-convert: make convert_rela() > list-safe"), convert_rela() still iterates through the section relas, > but only updates r1->sym->klp_rela_sec instead of moving them. > move_rela() was added to be called by the for-each-rela loop in > main(). > > - Bug 1: klp_rela_sec probably belongs in struct rela and not struct > symbol > > - Bug 2: the main loop skips over second, third, etc. matching relas > anyway as the shared symbol name will have already been converted Yes, it explains the issue. > The following fix might not be elegant, but I can't think of a clever > way to handle the original issue d59cadc0a8f8 ("[squash] klp-convert: > make convert_rela() list-safe") as well as these resulting regressions. > So I broke out the moving of relas to a seperate loop. It works. Thanks Joe. > That is probably > worth a comment and at the same time we might be able to drop some of > these other "safe" loop traversals for ordinary list_for_each_entry. I think _safe from list_for_each_entry_safe(rela, tmprela, &sec->relas, list) in the main loop could be dropped, because convert_rela() only marks relas and does not move them anywhere. Similarly, list_for_each_entry_safe(r1, r2, &oldsec->relas, list) in convert_rela() itself. Miroslav