From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752317AbdHJLM3 (ORCPT ); Thu, 10 Aug 2017 07:12:29 -0400 Received: from mx2.suse.de ([195.135.220.15]:33014 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751932AbdHJLM1 (ORCPT ); Thu, 10 Aug 2017 07:12:27 -0400 Date: Thu, 10 Aug 2017 13:12:25 +0200 (CEST) From: Miroslav Benes To: Jason Baron cc: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, jpoimboe@redhat.com, jeyu@kernel.org, jikos@kernel.org, pmladek@suse.com Subject: Re: [PATCH 0/3] livepatch: introduce atomic replace In-Reply-To: <2476c7a9-e962-8c20-2cf1-41befdd8ef95@akamai.com> Message-ID: References: <2476c7a9-e962-8c20-2cf1-41befdd8ef95@akamai.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) 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 > Ok - associating the "atomic replace" with the patch itself makes sense to me. > It would also basically work, I think with the patch I proposed except for the > case where the the "atomic replace" was on top of several non-"atomic replace" > patches. The reason is that the "atomic replace" I posted looks back 1 patch > to see what it needs to replace (assuming all patches are in atomic replace > mode). So instead of just looking back 1 patch, it could 'look back' and make > sure it was replacing all previously loaded patches. Yes, this should not be a problem to implement with the current code. But I must say I am not entirely happy with the code as it is. The big advantage is that there are almost no changes to the consistency model. Almost everything is created and allocated during the initialization and the patch then looks ordinary. The current code can handle it smoothly. "Dynamic" superstructure is what I am not happy with. It is too complicated in my opinion. On the other hand I don't see a simple way out now. 1. We can try to make your code "nicer". 2. The main problem is that all user structures (klp_func, klp_object, klp_patch) are statically allocated in a kernel module. You need to add dynamically allocated structures, which is not easy. We can either change everything to dynamic allocation, or make everything static. As far as the former is concerned, we've been down that road IIRC. It didn't end up well. Is the latter even possible? 3. We could bypass everything and register special no-op fops to each reverted function. Those could be held and handled separately. It could be simpler, but it might be problematic to deal with the consistency model interaction. Thoughts? Regards, Miroslav