Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3465097pxb; Wed, 13 Oct 2021 06:37:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy9IOZ4/PC7iqdSKuhMB2U1E2pdVZovRGI7bVLkI/7QsAfpWL/0+YQeDfWsU1GXLVMCI4yl X-Received: by 2002:a17:906:8cd:: with SMTP id o13mr39983766eje.341.1634132259939; Wed, 13 Oct 2021 06:37:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634132259; cv=none; d=google.com; s=arc-20160816; b=QBQxMDNUzu8chZshax6ME9PyPZf6CLTmLvlvjLl464gIujr8bHPedfmwF9AHqFSEUz 2kenpKlkVwdpO9hV4Tr7jqag6KjcQorFf5VeYyQ2RYR+OHtoX4WdKlKvicW7woxqghg3 sqyomECEoWYiCD6K8Xl64xYkCQoYLn6dDmEwyiO0j7npeYclqkDsk7ohvCUEW9SsLk5M TwirnleqXDlfm5xxLhRVgvwWle7fQh5abRbNR7CXYK2p8Og3rcKrvxUJzsL5EIELsRlY 4m5eot9aPl9wFch7lKF0iIfE4+v02+WOYn3+4EaB5UUie7rSbhOevhSrXa5sPUcEwOc5 64RA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=xgH0tfIhgrWD6+BGXfniS/dCqFos4XKJyLmg6tmJEwk=; b=UOyjJxhf6SHZ5kPeyNmT7QrhJWausAEy+JkDXEsTmWsRTkY0cByuuJHMUeJG0IhiEx 3STh0VzcLwf9BPGfj9jLcBbOJWbIngwbANIs/nm1Of8CH142H6HMIIwptG84iLH0qkn6 cEDRwWU5ELBIFLaRZqlJuutNBN4T4mYdmRz1PS7iKJx9Ft502eHv0ACXCfRoFmWYwOXJ uuAu0DofteiY2pNGc5A+PmiqK+wuwgUT+uTOfcfPukLyBqLR0u/Udzrk30kAQpRDw3e3 opqeflwpFXJzaYAb/xWRBgRs8Gw+yRpt4+blLRmFUwjBGssZAFgaHxgbb7La4IJetv9h anbg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g13si19279052ejw.289.2021.10.13.06.37.15; Wed, 13 Oct 2021 06:37:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233962AbhJMNfC (ORCPT + 99 others); Wed, 13 Oct 2021 09:35:02 -0400 Received: from foss.arm.com ([217.140.110.172]:39328 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229535AbhJMNfB (ORCPT ); Wed, 13 Oct 2021 09:35:01 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8F3B31FB; Wed, 13 Oct 2021 06:32:58 -0700 (PDT) Received: from e113632-lin (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 222203F66F; Wed, 13 Oct 2021 06:32:57 -0700 (PDT) From: Valentin Schneider To: Woody Lin Cc: Ingo Molnar , Ben Segall , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Mel Gorman , Daniel Bristot de Oliveira , linux-kernel@vger.kernel.org Subject: Re: [PATCH] sched/scs: Reset the shadow stack when idle_task_exit In-Reply-To: References: <20211012083521.973587-1-woodylin@google.com> <87zgrek1gl.mognet@arm.com> <87wnmijysj.mognet@arm.com> Date: Wed, 13 Oct 2021 14:32:51 +0100 Message-ID: <87tuhljbi4.mognet@arm.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/10/21 09:22, Woody Lin wrote: > On Tue, Oct 12, 2021 at 6:57 PM Valentin Schneider wrote: >> On 12/10/21 18:35, Woody Lin wrote: >> > unpoison looks more like an one-time thing to me; the idle tasks will >> > reuse the same stack pages until system resets, so I think we don't need >> > to re-unpoison that during hotplugging as long as it's unpoisoned in >> > 'init_idle'. >> > >> >> I would tend to agree, but was bitten by s390 freeing some memory on >> hot-unplug and re-allocating it upon hotplug: >> >> 6a942f578054 ("s390: preempt: Fix preempt_count initialization") >> >> This makes me doubt whether we can assert the idle task stack pages are >> perennial vs hotplug on all architectures. > > I made a quick study on memory-hotplug and seems that only memory contains > nothing other than migratable pages can be unplugged. So process stack > pages should not be a concern for this, since which is an unmovable > memory. > > However I don't have a chance to work on a system that enables > memory-hotplug so far, so couldn't verify this assumption further. Guess > we can create a separate thread to clarify this more. > That sounds sensible; I'll try to dig some more into this. As for the SCS change, someone might argue for placing this elsewhere in the hotplug path, but that looks fine to me: Reviewed-by: Valentin Schneider > Regards, > Woody > >> >> >> >> >> > } >> >> > >> >> > -- >> >> > 2.33.0.882.g93a45727a2-goog