Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4878477iob; Mon, 9 May 2022 03:54:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxKxOw87ZMro7y6hkzRVl1qNFHzW44w2KRKFCqm4SSyfnzxZ0AFDJUjK6QY9Y+mpGg+vWZl X-Received: by 2002:a65:614e:0:b0:380:bfd9:d4ea with SMTP id o14-20020a65614e000000b00380bfd9d4eamr12620814pgv.92.1652093692772; Mon, 09 May 2022 03:54:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652093692; cv=none; d=google.com; s=arc-20160816; b=MusX9vB5no12SCcAo5CcZQOaZyqbP9yeB0EHljayrgTpA6++17/MSU/Sul1OccKlbX KfYVEgYsd2qVszQOeULyUT03zP1eTBcgjKUiy1B3QEuXlYGXZ1cS2KYE5ZX92Ieq/Gnn ajEC2y/fxs+0c8wwfNsecwwMTAFpIIIdF3Jl3eczfHzjs+1NWquy+ayR3XNX3I/EixUf B1fojJyoYJFjoqTVZDk6mDBxfUpq61XO7Lss9+D6dm1/2z3FWDVPwfZ7vkwNtKuu/gq0 7DbGRTEeUe2EgxwXhjyoxMPj63iEFQqvJm7TrjFoBO4tingEdXbRQwY4CCjLHlPVooAD be3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=nLK8eWwMwyEnxqoOkhtH1DIuNWfIgfaMc34pifqEJGk=; b=0VhIC00Ue1uUOl9DKVmT5zYo1LPpO/Mk7e70sooEj7WMqETLk+AXoRCumtx/5AW91x h6ccwhr3lOa5ACZlFWRuNxuXXEcfkQ01kyI7KMG29HP+U+pAZpvtbE1RDMxliln49OM/ Dh+lO+18YBBeKkB0iUF3SXJdhhLqveMu59Ir7rK2jnUfzZw+V33sz3k2CBvSrmlAMhju Ee0EfgFk4LGPo4U3LDKvnatU/0zKYgfbiVKk3j6lUW16zwcPCPKYZzgHJYqiBngJ/BIN X+Kr+tTGT9+H9gtxhcfdGsZLfCgE/eRLcZw4lUtbnxwg26xtSBngE0AqIUFE4quCW4Ds 2aMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=SYBIrc5u; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id e19-20020a056a001a9300b00506855d333bsi13860023pfv.346.2022.05.09.03.54.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 May 2022 03:54:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=SYBIrc5u; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A0DE023AF0A; Mon, 9 May 2022 03:11:43 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233692AbiEIJz2 (ORCPT + 99 others); Mon, 9 May 2022 05:55:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235636AbiEIJnc (ORCPT ); Mon, 9 May 2022 05:43:32 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD0C81E05B8; Mon, 9 May 2022 02:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=nLK8eWwMwyEnxqoOkhtH1DIuNWfIgfaMc34pifqEJGk=; b=SYBIrc5uYnZo9IAFVdZI26vEhj Kar5mCVfxlcJW9ri5PuY0ZWsst8r8Fc3J1GnveaY0SUfAL1tzxXgfCCM6IVxpFGf3wnyvvY/T/SeL xT6pCazVk/b+9d+o65UNUTJW90J2j32kRubdkxOt14L4e+q1ckFMWNohWSjyGUAF5/rFDSdv8XevD gmD73r+JVQ3es/L7AtVBGiUf+gIDqQJCf0Gk/61hmDxgmraf2NdYMcdC4k6Rpf1iPoafiaVtf7DY1 EJSrEavNG1PW5KRGndOZB2IESYSNUbmr5JnaV9O4YSyXD/klu1A6R46uHqb8Yb+lhjS0tbo9PjeDw G/FFTMwQ==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=worktop.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1nnzqb-003JrU-On; Mon, 09 May 2022 09:38:33 +0000 Received: by worktop.programming.kicks-ass.net (Postfix, from userid 1000) id A07D9980E93; Mon, 9 May 2022 11:38:30 +0200 (CEST) Date: Mon, 9 May 2022 11:38:30 +0200 From: Peter Zijlstra To: Song Liu Cc: Song Liu , Linux Kernel Mailing List , "live-patching@vger.kernel.org" , Ingo Molnar , "vincent.guittot@linaro.org" , Josh Poimboeuf , "joe.lawrence@redhat.com" , Kernel Team Subject: Re: [RFC] sched,livepatch: call klp_try_switch_task in __cond_resched Message-ID: <20220509093830.GH76023@worktop.programming.kicks-ass.net> References: <20220507174628.2086373-1-song@kernel.org> <20220509070437.GC76023@worktop.programming.kicks-ass.net> <9FA1822F-76EE-4174-86DD-B20F1F8CE7FC@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9FA1822F-76EE-4174-86DD-B20F1F8CE7FC@fb.com> X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 09, 2022 at 08:06:22AM +0000, Song Liu wrote: > > > > On May 9, 2022, at 12:04 AM, Peter Zijlstra wrote: > > > > On Sat, May 07, 2022 at 10:46:28AM -0700, Song Liu wrote: > >> Busy kernel threads may block the transition of livepatch. Call > >> klp_try_switch_task from __cond_resched to make the transition easier. > > > > What will a PREEMPT=y kernel do? How is it not a problem there, and if > > it is, this will not help that. > > > > That is; I don't think this can be right. > > I guess on PREEMPT=y kernel, we can simply preempt the long running > kernel thread and check the transition? This is not a guessing game. > In this case (PREEMPT=n), we see a long running kernel thread could not > finish the transition. It calls cond_resched() and gets rescheduled > (moves among different cores). However, it never finishes the transition, > because live patch doesn’t get a chance to check the stack. > > Does this answer the question? Not really. There is no difference between an explicit preemption point (cond_resched) or an involuntary preemption point (PREEMPT=y). So unless you can *exactly* say why it isn't a problem on PREEMPT=y, none of this makes any sense.