On Mon, 2022-06-13 at 17:46 +0200, Diederik de Haas wrote: > On Monday, 13 June 2022 16:56:35 CEST Ben Hutchings wrote: > > We made the decision that the benefits of sandboxing with user > > namespaces are likely to outweigh the risks, on most systems. Nothing > > you've said convinces me to alter that assessment. > > I don't really/fully understand this topic, but I did look into it and from > the Kconfig file I understood that it was (highly?) recommended to also enable > CONFIG_MEMCG, while is defined as '=y' in debian/config/config. > So that seems great. > > What I also found was the following in debian/config/armel/config.marvell: > # CONFIG_MEMCG is not set > > Salsa commit fac721e3016478d286254eff2658954b15a70190 seems to be the 'cause' > for that and commit title is "[armel] Fold config-reduced into config.marvell" > Lots of changes in that commit, but I didn't see an explicit reason why > CONFIG_MEMCG should be disabled (IIUC) on that platform. > Is that something that needs to be corrected? (Just asking, I have no idea) Many (most?) of the machines supported by that configuration have a dedicated kernel partition in flash, so we try to limit the kernel image size. That was one of the options that added significantly to the image size and seemed less likely to be needed on armel. I don't know whether it still makes sense to disable it, since we gave up on fitting into 2 MiB partitions. Ben. -- Ben Hutchings It's easier to fight for one's principles than to live up to them.
Attachment:
signature.asc
Description: This is a digitally signed message part