On Fri, Oct 17, 2025 at 02:27:53PM +0200, Sumanth Korikkar wrote: > On Tue, Sep 23, 2025 at 02:17:04PM -0700, Andrew Morton wrote: > > On Tue, 23 Sep 2025 13:52:09 +0200 Sumanth Korikkar > > <[email protected]> wrote: > > > > > > --- a/fs/hugetlbfs/inode.c > > > > +++ b/fs/hugetlbfs/inode.c > > > > @@ -96,8 +96,15 @@ static const struct fs_parameter_spec > > > > hugetlb_fs_parameters[] = { > > > > #define PGOFF_LOFFT_MAX \ > > > > (((1UL << (PAGE_SHIFT + 1)) - 1) << (BITS_PER_LONG - > > > > (PAGE_SHIFT + 1))) > > > > > > > > -static int hugetlbfs_file_mmap(struct file *file, struct > > > > vm_area_struct *vma) > > > > +static int hugetlb_file_mmap_prepare_success(const struct > > > > vm_area_struct *vma) > > > > { > > > > + /* Unfortunate we have to reassign vma->vm_private_data. */ > > > > + return hugetlb_vma_lock_alloc((struct vm_area_struct *)vma); > > > > +} > > > > > > Hi Lorenzo, > > > > > > The following tests causes the kernel to enter a blocked state, > > > suggesting an issue related to locking order. I was able to reproduce > > > this behavior in certain test runs. > > > > Thanks. I pulled this series out of mm.git's mm-stable branch, put it > > back into mm-unstable. > > Hi all, > > The issue is reproducible again in linux-next with the following commit: > 5fdb155933fa ("mm/hugetlbfs: update hugetlbfs to use mmap_prepare")
Andrew - I see this series in mm-unstable, not sure what it's doing there as I need to rework this (when I get a chance, back from a 2 week vacation and this week has been - difficult :) Can we please drop this until I have a chance to respin? Thanks, Lorenzo
