From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29410ECAAA1 for ; Fri, 9 Sep 2022 20:03:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E4AB8D0002; Fri, 9 Sep 2022 16:03:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66D018D0001; Fri, 9 Sep 2022 16:03:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E6958D0002; Fri, 9 Sep 2022 16:03:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 388FF8D0001 for ; Fri, 9 Sep 2022 16:03:21 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id EE56B120933 for ; Fri, 9 Sep 2022 20:03:20 +0000 (UTC) X-FDA: 79893621360.30.7097480 Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) by imf28.hostedemail.com (Postfix) with ESMTP id 923F3C00B4 for ; Fri, 9 Sep 2022 20:03:20 +0000 (UTC) Received: by mail-yb1-f170.google.com with SMTP id g5so4218724ybg.11 for ; Fri, 09 Sep 2022 13:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=IkMJ11xanFBA1A+VwvFUFaLt9zTq4tiOVijRSx7WOio=; b=MDIXiFpWL1hpVrK2BxOvEtjZEJtOtZOqWijBOHfH+ZofmrZh6x9mw5kGsZTJMdd+g6 kYnX7RquEwrpVHf3CV3F/rC7Pkam/yXWpD2UifrfWpvrvni8Yp/TXJLh2+iIpgnd8yjo vVK7i/UwleLdYzisRPOU2pt05puHHYRSJXaR+SJW5wQhYwvK89TzdE4ihuj0o1i+lI2Z xsvfzOlmZCnb4Z9e67S4B1zVV2Fb0xA6fbAqZhZrF9oXCUwxJNmEgHNuvefoXlBQ2x98 Fm9GPnEfuCqEoOfKoNaHt1eL275ewe5TqXxpwR+pXT+/7WYQorQ1kJXz++uIT6oflP+k fAHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=IkMJ11xanFBA1A+VwvFUFaLt9zTq4tiOVijRSx7WOio=; b=NeQtoMm7jOWRT/CmG1ny4acZKI8SsooyHsbSFbO0YRYampA2kYarvPJuz+z1bZrKyo QZ0UzUJSCqnikuejhTM7WMekU46h9L6GAGa27No6m0jhPfWljM4xNjbfl/nGiY3DD46q +j10wMtoB45x0m/xsrzScW5Jqm71N6C7Qgn18bHqLBpzV5HTjbg+RRPJHdr3aiOG+RVf pouBGCJcSlN4s/1Jxo3uzC4KhZj17EAZqLwwpJbXd5Aq3kfCIhRj8OZenxLTJWTADzsK PTO6rsunGNLyTvOEgF7/ULgtQZXY7lrFNCUj2a9wXL2X0ipfUEeJHQm6msgPE2HM4F6j uwOA== X-Gm-Message-State: ACgBeo0RKEWRSg87ue0+/FkRFxuB+HSAdMMMlro3B093d6r37tilQGfZ Jh/rqjh9eqMJtjanjGuLtU7GarXcMy6jFCkSt+wTbQ== X-Google-Smtp-Source: AA6agR5vKXTrBodSE9/Tk6FKbY22qG2Co0KUqNH81FVLTEF70rjePGeqRbL/xka3r0Do8CBE6GreTjjJnI3M1ffq1+E= X-Received: by 2002:a25:d209:0:b0:6a8:e5f1:f179 with SMTP id j9-20020a25d209000000b006a8e5f1f179mr12691798ybg.380.1662753799612; Fri, 09 Sep 2022 13:03:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Suren Baghdasaryan Date: Fri, 9 Sep 2022 13:03:08 -0700 Message-ID: Subject: Re: BUG in binder_vma_close() at mmap_assert_locked() in stable v5.15 To: Carlos Llamas Cc: Andrew Morton , "Liam R. Howlett" , Michal Hocko , Guenter Roeck , Douglas Anderson , Christian Brauner , Greg Kroah-Hartman , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662753800; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IkMJ11xanFBA1A+VwvFUFaLt9zTq4tiOVijRSx7WOio=; b=fkX01oMas91svMU2EaS0LvxkPZncY6lU6Wax+O10ba3TeW20nYZ8YrHXqFEaqk8D160o3q fXPtGVdwVkFtqHXCyqmdDm/xvBNrYAxlRhHt31ANKumSn5+yiMCBpW6D3y9304WswU3Q3V XzVo0ho2AP+vync77799kUX220PQf7Q= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=MDIXiFpW; spf=pass (imf28.hostedemail.com: domain of surenb@google.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662753800; a=rsa-sha256; cv=none; b=rEPKjOf89CX0aCdPcrfQJGOFu6jWnaAMcYT6c6z9TmILhssuLZqWv57klg299wmG8/NN8i GQ3lk0VRpu5y6qtou1o6MJLBMtivNtZASks9fPRrZVeeRXwSXpqHR11ZSaKToEBw8BawMH 0UonDVkQGsBsL0P3/6g8ntnjQz9jV2g= X-Rspam-User: Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=MDIXiFpW; spf=pass (imf28.hostedemail.com: domain of surenb@google.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam06 X-Stat-Signature: c1kpig9kf6d3hxcx1azkdog7rbdszemo X-Rspamd-Queue-Id: 923F3C00B4 X-HE-Tag: 1662753800-218077 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Sep 9, 2022 at 12:35 PM Carlos Llamas wrote: > > On Thu, Sep 08, 2022 at 03:33:52PM -0700, Suren Baghdasaryan wrote: > > > However, mmap_locking was only added to the exit_mmap() path in commit > > > f798a1d4f94d ("mm: fix use-after-free bug when mm->mmap is reused after > > > being freed") and since this patch doesn't exist in v5.15 stable tree > > Sorry, I meant 64591e8605d6 ("mm: protect free_pgtables with mmap_lock > write lock in exit_mmap") here, that's when protection was added. > > > IIUC, the binder patches are backported to 5.15 kernel and they expect > > mmap_lock to be held during remove_vma() operation in exit_mmap(). > > Correct! > > > However in 5.15 kernel that assumption is incorrect. In that case IMHO > > the backport needs to drop that invalid expectation. > > Does this mean that users of async calls such as find_vma() can't rely > on mmap_lock to avoid racing with remove_vma()? I see the following > pattern is used quite often: > > mmap_read_lock(mm); > vma = find_vma(mm, addr); > [...] > mmap_read_unlock(mm); > > Is this not a real concern? I'd drop the asserts from binder and call it > a day. However, we would also need to fix our race with vm_ops->close(). I think by the time exit_mmap() calls remove_vma() there can be no other user of that mm to race with, even oom-reaper would have finished by then (see: https://elixir.bootlin.com/linux/v5.15.67/source/mm/mmap.c#L3157). So, generally remove_vma() would be done under mmap_lock write protection but in case of exit_mmap() that's not necessary. Michal, please correct me if I'm wrong.