Received: by 2002:ab2:69cc:0:b0:1f4:be93:e15a with SMTP id n12csp19810lqp; Fri, 12 Apr 2024 09:22:00 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCW6qVHoNcMWcGrZPtqs5SC+uGLg5SC+hJ8vS54EhktC3ZtUFwZqMaarQqbHCojUZ/PC6M1pSfZvrsjPpARbbSsCCttNS8un9A8jez6EGA== X-Google-Smtp-Source: AGHT+IH2XNLrsuSTb5yxVTWRPBZcdeL9WC+aPLhfs86Pjw0n9CezrgKiBoUt+WF2wKBrcm0wRm6M X-Received: by 2002:a50:d611:0:b0:56f:e609:743 with SMTP id x17-20020a50d611000000b0056fe6090743mr2161675edi.35.1712938920741; Fri, 12 Apr 2024 09:22:00 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712938920; cv=pass; d=google.com; s=arc-20160816; b=MLmGV71cvCaYy8VNnf+rxkvMnok3F2yOo9VFHVpiWnNVh20a5VFn6rsjntWoONtq2X 6jpPiJcKLhrwTDj6VDeoxnZHF63e9CTYOyziFmqG90IKnuV+8ii04g8l+h2Tp8tNaqsM H9GZeqN3+syyXZC3gwCjOMC4VF5rwGIW09kPuIIm3tXgmrwpejWIP42xjQIc5Rs5nV0h sJoHrjLohRW0RwHbX/ItS07uCDJ2YB9Zgam4UgFcJN/bEOognoGgmY1v0s0Y5ET+QRjh 5A1+FmV0I1baHNBWfs6ds0cOkinuWRllPF1S6L5qkeTogXIMoJmup/cBEEI3ItovxWqE vawA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date; bh=2hF5iFMhA3ZZAG31ytitAW4VhYpLG5nNPaxSnIWdFN0=; fh=Xm/5ExiaKE8wXtSEIoqa9sOBGJVlTaeQUVQG6W+ntWM=; b=hRpLwX6y3OxzRU/XaU3r0tHhEBjgI3QOG+8+qvvEFOL3CEHAlMP3n8X++KT5H9A/ri 3yeSUh1/uB/6+mAuYmKTYBVFm1SO3I1FuhdAa+Z22QPIoLvK+1zlVkY6MC8OJ+7bfc6+ mEF/6u45KfFrd3Hc6ba6/S2SPUksJejdOtEt47h6x3iKAKRi3Qrb+J74fbYyr0rNyh9F URf3tOl3Ynu/jR/Q0eypJ8+rDhvg5dsvIoTO/RrAfiS1HQdrS3oIqArkf82rMzJXKwZD wsK1zZUSRyDQkSnUQWfsIO926E7lV8nbbLBLKlFtaN/BhB5jajQzHKrZAotbzQzLwLrt SxIQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-143055-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-143055-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id b12-20020a056402278c00b0056e87a5115esi1766375ede.658.2024.04.12.09.22.00 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Apr 2024 09:22:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-143055-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-143055-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-143055-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 4FED71F236CD for ; Fri, 12 Apr 2024 16:21:50 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9D8B314A4D4; Fri, 12 Apr 2024 16:20:24 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BE02B14A4D0 for ; Fri, 12 Apr 2024 16:20:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712938824; cv=none; b=h/+stMicBnnPs+51/k4wBZyidErAMDOkZWPzlFMq9WiDWMgtn3yybWwSyxEG5nvTYtDH3dhcRQugTKDsuowac+sH4veFj7mcUKidPJMqyMnUk4jdLmodMAqCwYdOnf63JpbOl5k2TX8bmV3SaNqt5l3mrhGLwken9ySnwhORxDs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712938824; c=relaxed/simple; bh=JcFWIlWAmP82bnMMOxigsCewAls5gbc2qooWyldRIlo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZneJsRP2TX1Kl7K85v1fcxB3g24oIuxUPOQ9U4ycDUeREmZvQhVW6sIB1GeZQXoTYRA/ClbWBFsBRp5FwO5DGNiYt3I0XZ+fq7Uuhv1e1txA4Nv88hDf9FktW0XtiXToDTizlbu9CrlbroOAiIVo2z3tj3z6Kweq7Q3QFkg6ys8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 40FAB339; Fri, 12 Apr 2024 09:20:51 -0700 (PDT) Received: from e133380.arm.com (e133380.arm.com [10.1.197.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 482AE3F64C; Fri, 12 Apr 2024 09:20:19 -0700 (PDT) Date: Fri, 12 Apr 2024 17:20:16 +0100 From: Dave Martin To: Amit Singh Tomar Cc: Reinette Chatre , James Morse , x86@kernel.org, linux-kernel@vger.kernel.org, Fenghua Yu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , Babu Moger , shameerali.kolothum.thodi@huawei.com, D Scott Phillips OS , carl@os.amperecomputing.com, lcherian@marvell.com, bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com, baolin.wang@linux.alibaba.com, Jamie Iles , Xin Hao , peternewman@google.com, dfustini@baylibre.com, David Hildenbrand , Rex Nie Subject: Re: [EXTERNAL] Re: [PATCH v1 28/31] x86/resctrl: Drop __init/__exit on assorted symbols Message-ID: References: <20240321165106.31602-1-james.morse@arm.com> <20240321165106.31602-29-james.morse@arm.com> <47af4fef-35d3-4d88-9afa-42c1a99fbe07@marvell.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47af4fef-35d3-4d88-9afa-42c1a99fbe07@marvell.com> On Thu, Apr 11, 2024 at 09:21:38PM +0530, Amit Singh Tomar wrote: > Hi Dave, Reinette, > > > On Mon, Apr 08, 2024 at 08:32:36PM -0700, Reinette Chatre wrote: > > > Hi James, > > > > > > On 3/21/2024 9:51 AM, James Morse wrote: > > > > Because ARM's MPAM controls are probed using MMIO, resctrl can't be > > > > initialised until enough CPUs are online to have determined the > > > > system-wide supported num_closid. Arm64 also supports 'late onlined > > > > secondaries', where only a subset of CPUs are online during boot. > > > > > > > > These two combine to mean the MPAM driver may not be able to initialise > > > > resctrl until user-space has brought 'enough' CPUs online. > > > > > > > > To allow MPAM to initialise resctrl after __init text has been free'd, > > > > remove all the __init markings from resctrl. > > > > > > > > The existing __exit markings cause these functions to be removed by the > > > > linker as it has never been possible to build resctrl as a module. MPAM > > > > has an error interrupt which causes the driver to reset and disable > > > > itself. Remove the __exit markings to allow the MPAM driver to tear down > > > > resctrl when an error occurs. > > > > > > Obviously for the reasons you state this code has never been exercised. > > > Were you able to test this error interrupt flow yet? > > > > > > Reinette > > > > > > > I think this will have to wait for James to respond. > > > > There is code to tear down resctrl in response to an MPAM error interrupt, > > but I don't know how it has been exercised so far (if at all). > > We are managed to test the MPAM error interrupt (on the platform that > supports MPAM interrupts on software errors). For instance programming > more resource control groups (part IDs) than available, and It appears to > correctly remove the "resctrl" mount point (though mount command still shows > resctrl on /sys/fs/resctrl type resctrl (rw,relatime) > ), but Thanks for trying this out! Is it possible to unmount resctrl once the system is in this state? > # mount -t resctrl resctrl /sys/fs/resctrl > mount: /sys/fs/resctrl: mount point does not exist. What if you now try to mount resctrl somewhere else, e.g.: # mount -t resctrl resctrl /mnt I'm guessing this _should_ fail if you weren't able to unmount resctrl, since resctrl seems to forbid multiple mount instances. I'm not sure what the best behaviour is here. Leaving resctrl "half- mounted" might be a good thing: at this point the system is in a semi- bad state we want to make sure it can't be remounted. Unregistering the resctrl filesystem from the fs core feels cleaner if feasible though. Leaving an impossible unmount operation for init to do during reboot/ shutdown feels unfortunate. We might have to look at what other filesystems do in this area. The mount machinery does provide other ways of getting into broken, impossible situations from userspace, so this doesn't feel like an entirely new problem. > > Additionally, a question regarding this, Is a complete system restart > necessary to regain the mount? > > Thanks > -Amit I think James will need to comment on this, but I think that yes, it is probably appropriate to require a reboot. I think an MPAM error interrupt should only happen if the software did something wrong, so it's a bit like hitting a BUG(): we don't promise that everything works 100% properly until the system is restarted. Misbehaviour should be contained to MPAM though. Cheers ---Dave