On Sat, Jun 13, 2020 at 9:12 PM Mike Kravetz <mike.kravetz@xxxxxxxxxx> wrote: > > On 6/12/20 11:53 PM, Amir Goldstein wrote: > As a hugetlbfs developer, I do not know of a use case for interoperability > with overlayfs. So yes, I am not too interested in making them work well > together. However, if there was an actual use case I would be more than > happy to consider doing the work. Just hate to put effort into fixing up > two 'special' filesystems for functionality that may not be used. > > I can't speak for overlayfs developers. As I said, I only know of tmpfs being upper layer as a valid use case. Does that work with hugepages? How would I go about testing that? > > I agree with Colin's remark about adding limitations, but it would be a shame > > if overlay had to special case hugetlbfs. It would have been better if we could > > find a property of hugetlbfs that makes it inapplicable for overlayfs > > upper/lower > > or stacking fs in general. > > > > The simplest thing for you to do in order to shush syzbot is what procfs does: > > /* > > * procfs isn't actually a stacking filesystem; however, there is > > * too much magic going on inside it to permit stacking things on > > * top of it > > */ > > s->s_stack_depth = FILESYSTEM_MAX_STACK_DEPTH; > > > > Currently, the only in-tree stacking fs are overlayfs and ecryptfs, but there > > are some out of tree implementations as well (shiftfs). > > So you may only take that option if you do not care about the combination > > of hugetlbfs with any of the above. > > > > overlayfs support of mmap is not as good as one might hope. > > overlayfs.rst says: > > "If a file residing on a lower layer is opened for read-only and then > > memory mapped with MAP_SHARED, then subsequent changes to > > the file are not reflected in the memory mapping." > > > > So if I were you, I wouldn't go trying to fix overlayfs-huguetlb interop... > > Thanks again, > > I'll look at something as simple as s_stack_depth. Agree. Thanks, Miklos
