Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp526359imm; Wed, 23 May 2018 00:50:06 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrVkQC/82HmmohoDKJ3EWQ/dM6F/q7WJ9VDBJ1HJMo7+LhnKJq5P2z0WsdCTDhr4+5JRxkU X-Received: by 2002:a17:902:9689:: with SMTP id n9-v6mr1810883plp.363.1527061806523; Wed, 23 May 2018 00:50:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527061806; cv=none; d=google.com; s=arc-20160816; b=yoGXFrw4XNklu5h59D2vHl0ZOw9sA6maulyyEQGaIpGGlH4BCMwPkMZml/lDW3Noz/ /UiWMjBPiv3yjdBTAOiIGyl54IxNpoM/qxj4PWyu6HwANo2yXUFsq+h7NNCMHwixn5aJ LerHoK4IjfnhBXhGRnr51GlzO+56yaxYK2rppY2cKTSGxkRAj967kkh4aITnFWo8uY/B hV2zJZREVaCaWEh6DG2EWOuCMwWtnu1/bhLa2Jozkz872feh1uLghC12csTcRfs5FwYa eWlm/jd8Sl9VYc0XOW7mLkPM9SNQYwmBEFsgpTaF/c08giLSm3vjsrse+AAkO8Z4dz0V SqzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=zV3w/hMaEZlt5Ie6fuv+688/gMqYqEyLbi1LK9Kgzpw=; b=DhZOYFWSVv15tR43oMzEfo2B7iJtDf2AN934IMDAYn6AtRyqNiGK1PoFpMwbodDBl6 CiaNtDLVh3eBrDPIFBclBJ5FLucrjbN1N/dKznqlKhw734blrotaZw7y2U/Iz6s6oAfx yIxpzaOuV1+bOnOr0ftCpaUglLkrczgS89Mku3COu+XuKbrct5x2gJVPH6zFDaIjHYMF mUpgb/I3eKK4NKI4FNy+7Qkcm2D4kouUrlOtPqvyLtdiBwL4wMVA1qYef55hXlh0L85X 2HhZNS/nZLpOpCmCVB6siuS0iXhV0dvANepG3ocg6DtLDF48LNWcCc5CPBoXczYP6oP7 ljlw== 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 d30-v6si18449244pld.528.2018.05.23.00.49.52; Wed, 23 May 2018 00:50:06 -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 S1754491AbeEWHsV (ORCPT + 99 others); Wed, 23 May 2018 03:48:21 -0400 Received: from mx2.suse.de ([195.135.220.15]:56854 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754467AbeEWHr4 (ORCPT ); Wed, 23 May 2018 03:47:56 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A2F0AAF34; Wed, 23 May 2018 07:47:54 +0000 (UTC) From: Petr Mladek To: Jiri Kosina , Josh Poimboeuf , Miroslav Benes Cc: Joe Lawrence , Jessica Yu , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Petr Mladek Subject: [PATCH] livepatch: Remove not longer valid limitations from the documentation Date: Wed, 23 May 2018 09:47:42 +0200 Message-Id: <20180523074742.20171-1-pmladek@suse.com> X-Mailer: git-send-email 2.13.6 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Semantic changes are possible since the commit d83a7cb375eec21f04 ("livepatch: change to a per-task consistency model"). Also data structures can be patched since the commit 439e7271dc2b63de37 ("livepatch: introduce shadow variable API"). It is a high time we removed these limitations from the documentation. Signed-off-by: Petr Mladek --- I have found this when working on v12 of the atomic replace. It looks like a no-brainer and does not conflict with the patchset, so ... ;-) Documentation/livepatch/livepatch.txt | 24 ------------------------ 1 file changed, 24 deletions(-) diff --git a/Documentation/livepatch/livepatch.txt b/Documentation/livepatch/livepatch.txt index 1ae2de758c08..2d7ed09dbd59 100644 --- a/Documentation/livepatch/livepatch.txt +++ b/Documentation/livepatch/livepatch.txt @@ -429,30 +429,6 @@ See Documentation/ABI/testing/sysfs-kernel-livepatch for more details. The current Livepatch implementation has several limitations: - - + The patch must not change the semantic of the patched functions. - - The current implementation guarantees only that either the old - or the new function is called. The functions are patched one - by one. It means that the patch must _not_ change the semantic - of the function. - - - + Data structures can not be patched. - - There is no support to version data structures or anyhow migrate - one structure into another. Also the simple consistency model does - not allow to switch more functions atomically. - - Once there is more complex consistency mode, it will be possible to - use some workarounds. For example, it will be possible to use a hole - for a new member because the data structure is aligned. Or it will - be possible to use an existing member for something else. - - There are no plans to add more generic support for modified structures - at the moment. - - + Only functions that can be traced could be patched. Livepatch is based on the dynamic ftrace. In particular, functions -- 2.13.6