From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754455AbbKMMqh (ORCPT ); Fri, 13 Nov 2015 07:46:37 -0500 Received: from mx2.suse.de ([195.135.220.15]:44103 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753316AbbKMMqf (ORCPT ); Fri, 13 Nov 2015 07:46:35 -0500 Date: Fri, 13 Nov 2015 13:46:34 +0100 (CET) From: Miroslav Benes To: Jessica Yu cc: Josh Poimboeuf , Petr Mladek , Rusty Russell , Seth Jennings , Jiri Kosina , Vojtech Pavlik , linux-api@vger.kernel.org, live-patching@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: module: save load_info for livepatch modules In-Reply-To: Message-ID: References: <1447130755-17383-1-git-send-email-jeyu@redhat.com> <1447130755-17383-3-git-send-email-jeyu@redhat.com> <20151112053228.GD30025@packer-debian-8-amd64.digitalocean.com> <20151112102404.GL4431@pathway.suse.cz> <20151112150345.GT2599@pathway.suse.cz> <20151112170501.GD4038@treble.hsd1.ky.comcast.net> <20151112221750.GA13513@packer-debian-8-amd64.digitalocean.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 Fri, 13 Nov 2015, Miroslav Benes wrote: > As for load_info, I don't have a strong opinion whether to keep it for all > modules or for livepatch modules only. I have. We cannot keep it, even for livepatch modules... In info->hdr there is a temporary copy of the whole module (see init_module syscall and the first parts of load_module). In load_module a final struct module * is created with parts of info->hdr copied (I'll get to that later). So if we saved info->hdr for later purposes we would just have two copies of the same module in the memory. The original one with !SHF_ALLOC sections and everything in vmalloc area, and the new final copy with SHF_ALLOC sections only. This is not good. If this is correct (and I think it is after some staring into the code) we need to do something different. We should build the info we need for delayed relocations from the final copy (or refactor the existing module code). The second problem... dynrela sections need to be marked with SHF_ALLOC flag, right? Perhaps it would be better not to do it and copy also SHF_RELA_LIVEPATCH sections. It is equivalent but not hidden somewhere else (in userspace "kpatch-build" tool). Miroslav From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miroslav Benes Subject: Re: module: save load_info for livepatch modules Date: Fri, 13 Nov 2015 13:46:34 +0100 (CET) Message-ID: References: <1447130755-17383-1-git-send-email-jeyu@redhat.com> <1447130755-17383-3-git-send-email-jeyu@redhat.com> <20151112053228.GD30025@packer-debian-8-amd64.digitalocean.com> <20151112102404.GL4431@pathway.suse.cz> <20151112150345.GT2599@pathway.suse.cz> <20151112170501.GD4038@treble.hsd1.ky.comcast.net> <20151112221750.GA13513@packer-debian-8-amd64.digitalocean.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jessica Yu Cc: Josh Poimboeuf , Petr Mladek , Rusty Russell , Seth Jennings , Jiri Kosina , Vojtech Pavlik , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, live-patching-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-api@vger.kernel.org On Fri, 13 Nov 2015, Miroslav Benes wrote: > As for load_info, I don't have a strong opinion whether to keep it for all > modules or for livepatch modules only. I have. We cannot keep it, even for livepatch modules... In info->hdr there is a temporary copy of the whole module (see init_module syscall and the first parts of load_module). In load_module a final struct module * is created with parts of info->hdr copied (I'll get to that later). So if we saved info->hdr for later purposes we would just have two copies of the same module in the memory. The original one with !SHF_ALLOC sections and everything in vmalloc area, and the new final copy with SHF_ALLOC sections only. This is not good. If this is correct (and I think it is after some staring into the code) we need to do something different. We should build the info we need for delayed relocations from the final copy (or refactor the existing module code). The second problem... dynrela sections need to be marked with SHF_ALLOC flag, right? Perhaps it would be better not to do it and copy also SHF_RELA_LIVEPATCH sections. It is equivalent but not hidden somewhere else (in userspace "kpatch-build" tool). Miroslav