Received-SPF: pass (google.com: domain of linux-kernel+bounces-165570-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <cb40c3e6-f678-45c7-b8e7-a6f337b51dfb@marvell.com>
Date: Wed, 1 May 2024 21:51:51 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 28/31] x86/resctrl: Drop __init/__exit on assorted
 symbols
To: Dave Martin <Dave.Martin@arm.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>,
        James Morse <james.morse@arm.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org, Fenghua Yu <fenghua.yu@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        Borislav Petkov <bp@alien8.de>, H Peter Anvin <hpa@zytor.com>,
        Babu Moger <Babu.Moger@amd.com>, shameerali.kolothum.thodi@huawei.com,
        D Scott Phillips OS <scott@os.amperecomputing.com>,
        carl@os.amperecomputing.com, lcherian@marvell.com,
        bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com,
        baolin.wang@linux.alibaba.com, Jamie Iles <quic_jiles@quicinc.com>,
        Xin Hao <xhao@linux.alibaba.com>, peternewman@google.com,
        dfustini@baylibre.com, David Hildenbrand <david@redhat.com>,
        Rex Nie <rex.nie@jaguarmicro.com>
References: <20240321165106.31602-1-james.morse@arm.com>
 <20240321165106.31602-29-james.morse@arm.com>
 <c27c7813-5744-4363-bb7b-f9fbe80fd549@intel.com>
 <ZhfzF8L6w1pgJJ1r@e133380.arm.com>
 <47af4fef-35d3-4d88-9afa-42c1a99fbe07@marvell.com>
 <ZhlfQKMg4xeA53SD@e133380.arm.com>
 <b87653fa-34e3-4124-a96f-f5d2b9730f10@marvell.com>
 <ZjEaA+YRPA+p9msM@e133380.arm.com>
Content-Language: en-US
From: Amit Singh Tomar <amitsinght@marvell.com>
In-Reply-To: <ZjEaA+YRPA+p9msM@e133380.arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?QkFuaWE4Myt6N0s1d2s4emE1YkxzcVdsaitkN2x6cW1yWDRHQmxGcmxZTWZq?=
 =?utf-8?B?d25kSXBZYTdIV1R0UEtwTTlBM0x5TkNJclFJbURMVHhWWVEycFFUcDEwNk1R?=
 =?utf-8?B?cmU3dUF2MWtjdVJDYU5qTE8wMmhtOGJFcEpTTmUyM2V6dzFjZE5MLzVSaTdZ?=
 =?utf-8?B?cytMbkxkYlFZY1lveC9IMXltVC9EMjhTcTI3Z3B6NDdHY09aVWN6dlFEWkdI?=
 =?utf-8?B?Q213ZkpWMy9pdmlUMGk0L0srY1Nka1l6d0dHVlIzNXBRUFhKcXkwMDBydndu?=
 =?utf-8?B?R2RnVmJNTUlrTVBaSGFvWHRCQVZjckNTSkVZQS9VTzFBclh0TmcyV0FxKzBq?=
 =?utf-8?B?SExmYjl5cjFZMXNJOG40N0pDUlpJU2xTRVJjb0FvVFYwMGpjWUxXNW5KUTdR?=
 =?utf-8?B?bnpkT3pWWW4wbkx3a1kxRnM1LzN4amZPQTdldFhYZjdWZFFyaVB5R3ZvNzQy?=
 =?utf-8?B?UUlacUdhb29UN05TUWtBb0pXWEpOU2dvZERidThFK1N6MlFSdHMvbUFhVTAw?=
 =?utf-8?B?bnBlWGEvWVhpeWxvYm5maXdHWVovb00rbDU4bzBoRDdTb1RRWllEQTdzUm83?=
 =?utf-8?B?UWoveVRIbURxZ3JQRjdMMTM3dERJMDRqUzJ5bGF5ZTdDZ2VDRjFSVzBDSlhm?=
 =?utf-8?B?NlY5OC9CTFNESzlvU3l6b3dMK3RrZGQyR3ZMMHBuL05BOFB4ZndYZTliOXRj?=
 =?utf-8?B?bTlld2pvRnUxcmMyZ1pOR0o5MzZrTktGeEFBMzJXdXVkcDJsb0xRWFFUc3FV?=
 =?utf-8?B?aFJMbk54RjdsMGdLZGc5RlVSRjRnMEZJaFFpMFRXSHNZUG9wckI1TWJzVkZz?=
 =?utf-8?B?a0IwbzVtS1o5YkZDM2VUUExlUlpYREY4YUhSQkpOVVBpdG1iRlp0VzE3TnAz?=
 =?utf-8?B?ZjNNMFIyK0k4cmNWTk40V0FUK0JNNHRLU2dFT3JwTmtPNnJ6OURSdzdRWEg1?=
 =?utf-8?B?ejB0VWdxTzBNQy81NzFwa1Q4aGhVWktMWkE2aDVKZzRGTWtualB1ZzAwYlE2?=
 =?utf-8?B?MER6TDJGNnB1MUQyT0JhVGJjd0lPTnU3U0Zic252RnJkbGROU3J4c1hXa3ZL?=
 =?utf-8?B?alhPOGt2WHZlNkd3a0pjS0lxZ3ZmZWVJY0IwaVU3bStuWmY1dlJMR1NPMmM1?=
 =?utf-8?B?enV0L2xkaDFhSG8yb044YVVXWmtneDJzSEF3QmFyelMxb2c3ZVltR2hnTFJk?=
 =?utf-8?B?dlNPajMvSkRDb3V0dldLcEFGc0w3bGJ1dS80dXhwd0RZZ1JMWTdlQnRWOVRZ?=
 =?utf-8?B?N1BLbXB0NEgxQlJEdytzeUpsc0ljR09RakJzMjhtTkJqa1p3WW1Mc2J3eGdV?=
 =?utf-8?B?UkhsT2g1MXZVMGhDVkZHZXNJRUZjTjQzM25ORStPUDFoczlnU2hxOTBnUnFt?=
 =?utf-8?B?czY0NGhYT282WGFGUE9mRlVnOWdzNXB5WkcxOENsTFg4U3QrK2l6cHozVmhI?=
 =?utf-8?B?eS9lb2kxdVVpSDJJUFhOSVJieEcrdHFSK2RsaFFJYlFVcHBGcmZTZWl0eVU0?=
 =?utf-8?B?UzBjejBQVkhSYWk3YjhBQTFiNnJydW1GMVU0N3VvNWQxRW1sNFIxaVZyajdU?=
 =?utf-8?B?QzBpOC9nc3NYUUFLVmUxNldSMDlyamZMSTc5dFZodUZ1VXhmODZpY3Q2b3pL?=
 =?utf-8?B?MzIrZldSeEhZK3FzWkVjTytQeGtrQ1p4WEZoV3VKcFlXa1VFU1IwRXVlRlho?=
 =?utf-8?B?Sy9ieGpDaWo2SVFqQTFVNmlXcUdvVEVnRkRlWWdqLzQrYm5BL01wdG55ck1n?=
 =?utf-8?B?UTBHd2I2cUdENmx0c1VIbzViTGsxaURMZHgvSHlwT1VURXdHSitPb01vNXNY?=
 =?utf-8?B?MHMrNGFzUTd1c0dlRm1BOWVhbWJ2dUZSYVdPMlNONCthTFMybG1FK05tejRl?=
 =?utf-8?B?dDZUK0VxSDZYbTloRjRycHJ6REp2clhFTXRVTUttdXVMNWVFdTA4WkFxRksw?=
 =?utf-8?B?cGRSaTg1VzJQM0J4VVRQMFhYcmxBb1FLSWRNbnpacjNDNGtzendXbGEwUHJT?=
 =?utf-8?B?MjRPcXVZbHcydGdhZmVSeFd0MUphdEc5SlU5TEU0dnZBcktWa3FNK0FtbklB?=
 =?utf-8?B?NTJQTGhmSjBKV2QrR205aXBwOUQ1cDZRWEQ5Y29QbGIrdjBSZC9NdjdQVnNK?=
 =?utf-8?Q?mg6gCcsQGxauMjpiiZpMiEUpq?=
X-OriginatorOrg: marvell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6399667d-140e-47fc-c954-08dc69fada49
X-MS-Exchange-CrossTenant-AuthSource: MW4PR18MB5084.namprd18.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2024 16:22:10.7929
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 70e1fb47-1155-421d-87fc-2e58f638b6e0
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: diy4yqZcjVFL/YaYfl27+JMHviLne4p3LvW0El2o6aOwSP2XfLIhgboFs49VkAs5rOyyFdLFiufE7XDA3EO4Lw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR18MB6041
X-Proofpoint-GUID: 3H6zONeAO6ltHlWTteLpfSTU2zw8UnRq
X-Proofpoint-ORIG-GUID: 3H6zONeAO6ltHlWTteLpfSTU2zw8UnRq
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1011,Hydra:6.0.650,FMLib:17.11.176.26
 definitions=2024-05-01_16,2024-04-30_01,2023-05-22_02


>>> 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.
>>>
>> if "resctrl" is nonfunctional in this state, then this comment[1] here does
>> *not* make sense.
>>
>> "restore any modified controls to their reset values."
> 
> Can you clarify what you mean here?

What I meant was, What's the rationale behind restoring the modified 
controls, if user is going to restart the system anyways (in order to 
use MPAM again), but later realized that it is needed so that *non* MPAM 
loads (user may still want to run other things even after MPAM error 
interrupt) would not have any adverse effect with modified controls.

Therefore, taking my statement back.

> 
> I think it makes sense to clean up the MPAM hardware as well as we can
> in these situations, even if we can't be certain what went wrong.
> 
> [final comments below]
> 
>> Thanks
>> -Amit
>>
>> [1]: https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_morse_linux.git_tree_drivers_platform_mpam_mpam-5Fdevices.c-3Fh-3Dmpam_snapshot_v6.7-2Drc2-23n2228&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=V_GK7jRuCHDErm6txmgDK1-MbUihtnSQ3gPgB-A-JKU&m=DzR4EYX-356bYvqcrD5mYQBzLmDppMaRaHx6yjN7nRE5GH7nogtw6VtDZchmqb_q&s=SKpVy4sPg3dbFJGfMfUGoo252IHOrHrLfcv5f0sCmm0&e=
>>
>> root@localhost:~# mount
>> tmpfs on /run/user/0 type tmpfs
>> (rw,nosuid,nodev,relatime,size=32923772k,nr_inodes=8230943,mode=700)
>> resctrl on /sys/fs/resctrl type resctrl (rw,relatime)
>>
>> root@localhost:~# devmem msc_addr 32 0x9999
>> [  687.096276] mpam: error irq from msc:1 'PARTID_SEL_Range', partid:39321,
>> pmg: 0, ris: 0
>>
>> root@localhost:~# mount
>> tmpfs on /run/user/0 type tmpfs
>> (rw,nosuid,nodev,relatime,size=32923772k,nr_inodes=8230943,mode=700)
>> resctrl on /sys/fs/resctrl type resctrl (rw,relatime)
>>
>> root@localhost:~# umount resctrl
>> umount: /sys/fs/resctrl: no mount point specified.
>>
>> root@localhost:~# mount
>> tmpfs on /run/user/0 type tmpfs
>> (rw,nosuid,nodev,relatime,size=32923772k,nr_inodes=8230943,mode=700)
>>
>> root@localhost:~# mount -t resctrl resctrl /test
>> mount: /test: unknown filesystem type 'resctrl'.
> 
> 
> Thanks for trying this out.
> 
> I guess the behaviour here might want a bit more thought.
> 
> I'm not too keen on us leaving a defective mount in the namespace,
> with a nonexistent mount pount.  I'm wondering whether things like
> systemd may get confused by this...
> 
> Cheers
> ---Dave