Received-SPF: pass (google.com: domain of linux-kernel+bounces-149244-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
From: Peter Xu <peterx@redhat.com>
To: linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Cc: peterx@redhat.com,
	David Hildenbrand <david@redhat.com>,
	Mina Almasry <almasrymina@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Muchun Song <muchun.song@linux.dev>,
	David Rientjes <rientjes@google.com>
Subject: [PATCH 0/3] mm/hugetlb: Fix missing hugetlb_lock for memcg resv uncharge
Date: Wed, 17 Apr 2024 17:18:33 -0400
Message-ID: <20240417211836.2742593-1-peterx@redhat.com>
Content-Type: text/plain; charset="utf-8"
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Should fix the recent syzbot report for:

https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/

Patch 1 is a small fixup where I notice mm-unstable crashes with the new
hugetlb memcg accounting when testing the changes.

Patch 2 should be the fix to the reported issue.

Patch 3 is an oneliner to add an assertion similar to what found the issue
in patch 2.

Only smoke tested over a bunch of hugetlb unit tests.  Reviews welcomed.

Thanks,

Peter Xu (3):
  fixup! mm: always initialise folio->_deferred_list
  mm/hugetlb: Fix missing hugetlb_lock for resv uncharge
  mm/hugetlb: Assert hugetlb_lock in __hugetlb_cgroup_commit_charge

 mm/hugetlb.c        | 5 ++++-
 mm/hugetlb_cgroup.c | 2 +-
 mm/memcontrol.c     | 1 +
 3 files changed, 6 insertions(+), 2 deletions(-)

-- 
2.44.0