Hello, Eric. On Tue, Aug 11, 2015 at 11:04:28PM -0500, Eric W. Biederman wrote: > ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > > > ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > > > >> I just went and attempted to reproduce this, and on RHEL6 workstation > >> (aka my work laptop), using the todays 4.2.0-rc6+ aka > >> edf15b4d4b01b565cb5f4fd2e2d08940b9f92e2f and all of the mounts in > >> /proc/self/mounts are the same between 4.2.0-rc6 and the RHEL6 stock > >> 2.6.32-504.30.3.el6.x86_64, including the cgroups mounted on /cgroup. > > > > I built a few more kernels just to see if this was some weird backport > > thing. The kernels 3.10.86, 3.14.58, 3.18.20, and 4.1.5 all boot and > > mount their cgroup filesystems just fine. Granted I kept having to > > smack the memory cgroup into being compiled in as the config options > > kept changing but otherwise I have not seen any problems. > > > > So I am very surprised you are having problems. > > Although I guess I could have saved myself some time by noticing that > 4.1.5 was the only one of the kernels with the change backported into > it. *Shrug* > > I don't see the problem and I don't know where to look to see why you > are having problems. lol, this wasn't upstart but an internal tool which sets up a custom cgroup hierarchy and the problem was the size of the directory inode reported by stat(2). It's kinda hilarious but that's what the tool was depending on to tell whether tmpfs is mounted on /sys/fs/cgroup or not. A kernfs directory reports zero as its inode size while tmpfs reports some non-zero number, so the tool did stat(2) on /sys/fs/cgroup and mounted tmpfs iff size is zero to avoid mounting tmpfs multiple times. Now, make_empty_dir_inode() sets i_size to 2 and the tool thinks that tmpfs is already mounted there. It's an icky behavior but it'd be better to maintain the original behavior. We should be able to set size to zero for empty dirs, right? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
