Hi Stephen, On 05/24/2013 12:29 PM, Stephen Mell wrote:
> Gu, > > On Friday, May 24, 2013 11:03:31 Gu Zheng wrote: >> Hi Stephen, >> >> On 05/24/2013 07:32 AM, Stephen Mell wrote: >> >>> On Thursday, May 23, 2013 18:20:57 Gu Zheng wrote: >>> >>>> Here it'll create a new proc sb instance which holds the same context as >>>> the old ones >>>> each time we mount proc though in the same PID namespace, won't it? >>> I believe so. But this is the point, right? > >> Yes, but I think it's also the problem. >> >>> They won't be identical if different mount options are used, I don't think. >> >> If different mount options are used, we'll create different super block >> instance, and they have >> the same context, only the difference is each one holds different >> proc_sb_info. >> But I think what we really want is only one proc sb instance and create >> different proc_sb_info >> if different mount options are used. > > Will having several different superblocks cause problems, or is it merely > inefficient? Not only inefficient. >I freely admit to not really knowing what I'm doing, and I thank you for your >assistance. > How is this situation distinct from that of ramfs? It appears to have a > superblock for each mount. They're different, each ramfs uses a split superblock to manage it's infos, e.g. the usage, and each ramfs mount instance should not affect others. But proc is a common interface, each mount instance holds the same context, so there's no need to create a new superblock instance each time mount if we in the same PID namespace. > It would seem to me as though one cannot have different sb_infos with the > same superblock, making storing the mount options in sb_info effectively the > same as storing them in the superblock itself, for the purposes of this > discussion. Where would the mount options be stored, if not in the superblock? > One fuzzy way in my mind, I'm not sure whether it's OK, but we can discuss it. Split hide_pid, pid_gid, and proc_self from pid_namespace, and create struct proc_sb_info(maybe the name "proc_mount_info" is better). And create a new list domain in the pid_namespace to contain the proc_sb_info instances. Each time we mount proc in a new directory only create a new proc_sb_info instance, and added it to the list in pid_namespace. But this leads to another problem, how to get the right proc_sb_info instance in proc permission checking routine, do you have any idea? what do you think of this way? Thanks, Gu >>> >>>> Here the pre-check seems needless. >>> Is that new with my patch, or has it always been needless? >> >> Yeah, it's always needless. >> >> Thanks, >> Gu >> >>> >>> Thanks, >>> Stephen > > Thanks again, > Stephen > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
