On Sun, Mar 26, 2017 at 09:03:33AM +0200, Djalal Harouni wrote: > (Cc'ed Kees and Jann for the procfs stacking issue) > > > I completely agree with you that it looks wrong when options of one > > mountpoint affect the others mountpoints. > > > >> I'm not sure if that's the right approach, it is still buggy, however > >> seems that your patch also stores the mount option inside the > >> pid_namespace which may get propagated to all mounts inside same pidns > >> ? > > > > I don't store 'pidonly' option in my current patch. I mean in: > > https://lkml.org/lkml/2017/3/20/363 > > > > I parse options twice at first mount of procfs. It happens before > > the mounting /proc in userspace. > > > > I know it's bad, but I couldn't find place to store this option. > > Ok, then maybe that approach of having a procfs struct holder instead > of using pid namespace may help! I deside to stop doing my patch. I talked with a few people and found out that the overlayfs doesn't feel very well if on the lower level filesystem appear/disappear files. In addition with the pidfs isn't so simple. Separate the root will lead to a doubling of memory consumption and restrictions on the filesystem operations level can easily be skipped. It means that even I can do this pidfs (or pid subset in /proc), it will be pointless. -- Rgrds, legion -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
