Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Song Liu <songliubraving@fb.com>
To:     Hugh Dickins <hughd@google.com>
CC:     Andrew Morton <akpm@linux-foundation.org>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
        Oleg Nesterov <oleg@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH] uprobes: __replace_page() avoid BUG in munlock_vma_page()
Thread-Topic: [PATCH] uprobes: __replace_page() avoid BUG in
 munlock_vma_page()
Thread-Index: AQHWdA4T+6PyWIZ5c0iaUFwxmwC/66k7ynEAgAAaeYCAAJOoAA==
Date:   Mon, 17 Aug 2020 16:06:19 +0000
Message-ID: <C1C463D2-39C5-413F-B99C-3F73B1C07BF1@fb.com>
References: <alpine.LSU.2.11.2008161338360.20413@eggly.anvils>
 <852258AE-75B6-404A-B236-9EEF37AEE43F@fb.com>
 <alpine.LSU.2.11.2008162340320.1025@eggly.anvils>
In-Reply-To: <alpine.LSU.2.11.2008162340320.1025@eggly.anvils>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <BE3B58A21F059F48890CB389F8ACC26A@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d496cdcc-9822-4fad-e910-08d842c77af3
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2020 16:06:19.9806
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Ai8AITWDAu3FCBd6ZEd4DwHt2EYuGWsfHe90XlR+9vi78gfvHPIHE40G6MIxsHwxN103DNP+QnrC+qokSfO4xA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2568
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687
 definitions=2020-08-17_13:2020-08-17,2020-08-17 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 suspectscore=0
 lowpriorityscore=0 impostorscore=0 phishscore=0 mlxscore=0 spamscore=0
 mlxlogscore=999 malwarescore=0 bulkscore=0 adultscore=0 clxscore=1015
 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2006250000 definitions=main-2008170119
X-FB-Internal: deliver
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Aug 17, 2020, at 12:17 AM, Hugh Dickins <hughd@google.com> wrote:
>=20
> On Mon, 17 Aug 2020, Song Liu wrote:
>>> On Aug 16, 2020, at 1:44 PM, Hugh Dickins <hughd@google.com> wrote:
>>>=20
>>> syzbot crashed on the VM_BUG_ON_PAGE(PageTail) in munlock_vma_page(),
>>> when called from uprobes __replace_page().  Which of many ways to fix i=
t?
>>> Settled on not calling when PageCompound (since Head and Tail are equal=
s
>>> in this context, PageCompound the usual check in uprobes.c, and the pri=
or
>>> use of FOLL_SPLIT_PMD will have cleared PageMlocked already).
>>>=20
>>> Reported-by: syzbot <syzkaller@googlegroups.com>
>>> Fixes: 5a52c9df62b4 ("uprobe: use FOLL_SPLIT_PMD instead of FOLL_SPLIT"=
)
>>> Signed-off-by: Hugh Dickins <hughd@google.com>
>>> Cc: stable@vger.kernel.org # v5.4+
>>> ---
>>> This one is not a 5.9-rc regression, but still good to fix.
>>>=20
>>> kernel/events/uprobes.c |    2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>=20
>>> --- v5.9-rc/kernel/events/uprobes.c	2020-08-12 19:46:50.851196584 -0700
>>> +++ linux/kernel/events/uprobes.c	2020-08-16 13:18:35.292821674 -0700
>>> @@ -205,7 +205,7 @@ static int __replace_page(struct vm_area
>>> 		try_to_free_swap(old_page);
>>> 	page_vma_mapped_walk_done(&pvmw);
>>>=20
>>> -	if (vma->vm_flags & VM_LOCKED)
>>> +	if ((vma->vm_flags & VM_LOCKED) && !PageCompound(old_page))
>>=20
>> Do we need munlock_vma_page() for THP page head?=20
>=20
> No: as the commit message says "the prior use of FOLL_SPLIT_PMD
> will have cleared PageMlocked already" - our THP implementation
> has difficulty supporting Mlocked consistently when the huge page is
> somewhere mapped by ptes, so one of the things that __split_huge_pmd()
> does is clear_page_mlock(), then PageDoubleMap will prevent Mlocked
> being set again once GUP has brought the old_page pte back in.
>=20
> But if you'd prefer us to munlock_vma_page(compound_head(old_page))
> instead, I can certainly change the patch: it's one of the options
> I considered, but couldn't quite bring myself to do it that way,
> knowing that actually it would never find PageMlocked set.  (If
> PageMlocked were allowed on tail pages, I'd have used a PageMlocked
> test instead of the PageCompound one: I spent nearly an hour
> bikeshedding the alternatives here!)
>=20
> (One day I must remind myself of when munlock_vma_page() should be
> used, versus when clear_page_mlock() should be used: I think it comes
> down to a choice of which stats get incremented, but I may also be
> forgetting something more important: anyway, no obvious reason to
> depart from the munlock_vma_page() that's always been used here.)

Thanks a lot for the explanation!

Acked-by: Song Liu <songliubraving@fb.com>