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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Wed, 1 May 2024 21:51:51 +0530
From: Amit Singh Tomar <amitsinght@...vell.com>
To: Dave Martin <Dave.Martin@....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


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