linux-kernel - Re: [PATCH v1 28/31] x86/resctrl: Drop __init/_

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZjEaA+YRPA+p9msM@e133380.arm.com>
Date: Tue, 30 Apr 2024 17:19:15 +0100
From: Dave Martin <Dave.Martin@....com>
To: Amit Singh Tomar <amitsinght@...vell.com>
Cc: Reinette Chatre <reinette.chatre@...el.com>,
	James Morse <james.morse@....com>, x86@...nel.org,
	linux-kernel@...r.kernel.org, Fenghua Yu <fenghua.yu@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	H Peter Anvin <hpa@...or.com>, Babu Moger <Babu.Moger@....com>,
	shameerali.kolothum.thodi@...wei.com,
	D Scott Phillips OS <scott@...amperecomputing.com>,
	carl@...amperecomputing.com, lcherian@...vell.com,
	bobo.shaobowang@...wei.com, tan.shaopeng@...itsu.com,
	baolin.wang@...ux.alibaba.com, Jamie Iles <quic_jiles@...cinc.com>,
	Xin Hao <xhao@...ux.alibaba.com>, peternewman@...gle.com,
	dfustini@...libre.com, David Hildenbrand <david@...hat.com>,
	Rex Nie <rex.nie@...uarmicro.com>
Subject: Re: [PATCH v1 28/31] x86/resctrl: Drop __init/__exit on assorted
 symbols

On Tue, Apr 30, 2024 at 12:43:05PM +0530, Amit Singh Tomar wrote:
> Hi Dave,
> 
> > Is it possible to unmount resctrl once the system is in this state?
> No, it can't be unmounted, as there is no mount exist.

I see.


> > > # 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
> root@...alhost:~# mount -t resctrl resctrl /test
> mount: /test: unknown filesystem type 'resctrl'.

Oh, right, so the resctrl filesystem gets unregistered in that
case...

> > 
> > 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.
> > 
> 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?

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://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git/tree/drivers/platform/mpam/mpam_devices.c?h=mpam/snapshot/v6.7-rc2#n2228
> 
> root@...alhost:~# 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@...alhost:~# devmem msc_addr 32 0x9999
> [  687.096276] mpam: error irq from msc:1 'PARTID_SEL_Range', partid:39321,
> pmg: 0, ris: 0
> 
> root@...alhost:~# 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@...alhost:~# umount resctrl
> umount: /sys/fs/resctrl: no mount point specified.
> 
> root@...alhost:~# mount
> tmpfs on /run/user/0 type tmpfs
> (rw,nosuid,nodev,relatime,size=32923772k,nr_inodes=8230943,mode=700)
> 
> root@...alhost:~# 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