From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753648AbcERQwG (ORCPT ); Wed, 18 May 2016 12:52:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37279 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932344AbcERQvu (ORCPT ); Wed, 18 May 2016 12:51:50 -0400 Date: Wed, 18 May 2016 11:51:47 -0500 From: Josh Poimboeuf To: Jiri Kosina Cc: Jessica Yu , Miroslav Benes , Ingo Molnar , Peter Zijlstra , Michael Ellerman , Heiko Carstens , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, Vojtech Pavlik , Jiri Slaby , Petr Mladek , Chris J Arges , Andy Lutomirski Subject: Re: livepatch: change to a per-task consistency model Message-ID: <20160518165147.vyuamqfnm5kfwiqf@treble> References: <20160517225357.GA30725@packer-debian-8-amd64.digitalocean.com> 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) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 18 May 2016 16:51:50 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 18, 2016 at 10:16:22AM +0200, Jiri Kosina wrote: > On Tue, 17 May 2016, Jessica Yu wrote: > > > What about tasks sleeping on affected functions in uninterruptible sleep > > (possibly indefinitely)? Since all signals are ignored, we wouldn't be > > able to patch those tasks in this way, right? Would that be an > > unsupported case? > > I don't think there is any better way out of this situation than > documenting that the convergence of patching could in such cases could > take quite a lot of time (well, we can pro-actively try to detect this > situation before the patching actually start, and warn about the possible > consequences). > > But let's face it, this should be pretty uncommon, because (a) it's not > realistic for the wait times to be really indefinite (b) the task is > likely to be in TASK_KILLABLE rather than just plain TASK_UNINTERRUPTIBLE. Yeah, I think this situation -- a task sleeping on an affected function in uninterruptible state for a long period of time -- would be exceedingly rare and not something we need to worry about for now. -- Josh