Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932348AbcDNNjz (ORCPT ); Thu, 14 Apr 2016 09:39:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45292 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753530AbcDNNjy (ORCPT ); Thu, 14 Apr 2016 09:39:54 -0400 Date: Thu, 14 Apr 2016 08:39:51 -0500 From: Josh Poimboeuf To: Miroslav Benes Cc: Jiri Kosina , Jessica Yu , linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Vojtech Pavlik Subject: Re: [RFC PATCH v1.9 14/14] livepatch: update task universe when exiting kernel Message-ID: <20160414133951.eydmvevb65jzse5e@treble> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1416 Lines: 31 On Thu, Apr 14, 2016 at 10:50:28AM +0200, Miroslav Benes wrote: > On Thu, 14 Apr 2016, Miroslav Benes wrote: > > > On Fri, 25 Mar 2016, Josh Poimboeuf wrote: > > > > > Update a tasks's universe when returning from a system call or user > > > space interrupt, or after handling a signal. > > > > > > This greatly increases the chances of a patch operation succeeding. If > > > a task is I/O bound, it can switch universes when returning from a > > > system call. If a task is CPU bound, it can switch universes when > > > returning from an interrupt. If a task is sleeping on a to-be-patched > > > function, the user can send SIGSTOP and SIGCONT to force it to switch. > > > > > > Since the idle "swapper" tasks don't ever exit the kernel, they're > > > updated from within the idle loop. > > > > Well, I am still not familiarized enough with Andy's recent rework of > > entry stuff, but I think all of this is correct. Maybe I would add > > a note to the changelog, that since TIF_KLP_NEED_UPDATE is defined 14th > > bit it is also automatically included in _TIF_ALLWORK_MASKS. > > And I forgot to add that I would try to prepare similar thing for s390 and > maybe powerpc (taking recent development there into account). That's gonna > be fun :) Yeah, good point. I've glanced at the entry code for both architectures and I don't think it'll be too bad, though the devil's in the details. -- Josh