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 34A42C54EE9 for ; Thu, 8 Sep 2022 20:28:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BAFF86B0072; Thu, 8 Sep 2022 16:28:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B5EF96B0073; Thu, 8 Sep 2022 16:28:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A27588D0002; Thu, 8 Sep 2022 16:28:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 9372B6B0072 for ; Thu, 8 Sep 2022 16:28:32 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 650D11C63D4 for ; Thu, 8 Sep 2022 20:28:32 +0000 (UTC) X-FDA: 79890056064.29.D06484A Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by imf01.hostedemail.com (Postfix) with ESMTP id 16D2140078 for ; Thu, 8 Sep 2022 20:28:31 +0000 (UTC) Received: by mail-pj1-f41.google.com with SMTP id m10-20020a17090a730a00b001fa986fd8eeso3457999pjk.0 for ; Thu, 08 Sep 2022 13:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :from:to:cc:subject:date; bh=1ncM7/d9Vr+SGv46w/FbU8BaNCshzWJ8scrlls0ICic=; b=h31g6wxl4et9NhCJLfvShB5d24vOGDoCFmoXFC02MDkqjyeVz1bA/vDz8NSg/hmCPO jkhsXv8kELLZginemlaj2cENjpuBGQf8qX7Q2poF2+ITRxi/4sSiU+AeT9eyqLMEmaU8 XCSOB6tdLZYFBNkxTUAtZpMBz5r83dEc/zmNxSKjZVS9Ed45kKg2lPweCc5y6uUmc3S5 jHyIrxET36N7RcC4sEqVz3QAe4Bc81Ubea8y/pNVnwVqZJcVqJWyznbSJkGW0nE4XvVF zYiAhXybGNPI8gA8vERCAmSd8X56bXbb2Udcx3HhrQ6IP2QszEWoUgkOCaavxZfOlhOj 3P0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date; bh=1ncM7/d9Vr+SGv46w/FbU8BaNCshzWJ8scrlls0ICic=; b=BGbO42rA1yaecrsIvJZ2Z/Kf0dIESoBKM5/bfcyTlf6YsYUCd87B1dw8EwktfMDVBf k/DgcTjYqJKMnPk4nnC+zmFRG1oneu1pY8eXeBy7pWib6Ys05nlzvguQ9JG1vJGA67Sk owy3mXFhepNjhgg50cEV1uNtW8wMQqj8KbBO8qf+gqb+pB/rxH9WyMfbAU+KkZST90Wp CALT+dzvfIG7NkfkTokILyIQCvr3OZ6Ht9WW4s+d+rgtgGorsFWDFcFdbUpu900q8mSh rgPlrhitI9stz3W0fwhdewRLt+pS89oX3rGDe+AMT/OzolrewdxnfBMrkb0tgZuCfcBx QvFw== X-Gm-Message-State: ACgBeo2n63ChMNwJPq3fDzkM5zTsJpB5yIdWmPvOw+EdRtSDrF03RGoI 3mfiArBBfItS+hCIbk0rrpQiTA== X-Google-Smtp-Source: AA6agR424lbg4Cj+rngYD34RaLFdBLiMgYpqjd7A2TjlGPNb4lPdQI8g7v4XYtSRLiIcw8kDbQ1MWg== X-Received: by 2002:a17:903:291:b0:172:f018:cdce with SMTP id j17-20020a170903029100b00172f018cdcemr10372426plr.91.1662668910721; Thu, 08 Sep 2022 13:28:30 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id a26-20020aa78e9a000000b0053fcb800ec0sm38813pfr.9.2022.09.08.13.28.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Sep 2022 13:28:30 -0700 (PDT) Date: Thu, 8 Sep 2022 20:28:26 +0000 From: Carlos Llamas To: Andrew Morton , Suren Baghdasaryan , "Liam R. Howlett" , Michal Hocko Cc: Guenter Roeck , Douglas Anderson , Christian Brauner , Greg Kroah-Hartman , linux-mm@kvack.org Subject: BUG in binder_vma_close() at mmap_assert_locked() in stable v5.15 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=h31g6wxl; spf=pass (imf01.hostedemail.com: domain of cmllamas@google.com designates 209.85.216.41 as permitted sender) smtp.mailfrom=cmllamas@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662668912; a=rsa-sha256; cv=none; b=ldxRIbtlCb5i9hk65ke4No01E2EzeONqW/LjkG8PWVQzLBS+0CwNTEvWHzc1UyOtt9r/pg M1I0ZrvPKdUx9VLcgc1Jv3w9NzCdRrcgPpcjhQUmXjp73kTB6CX926cjBCL9sz58mJ852o IGY3dpGDILBs5LQt42VnzoefXiMGFaU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662668912; 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: references:dkim-signature; bh=1ncM7/d9Vr+SGv46w/FbU8BaNCshzWJ8scrlls0ICic=; b=IoVm4XMMFb52m76cqbbROxFywoVlTI19W1TzARn5zJzJy3DB2Ysad/nCGgq3GelVV+2xaR tDgby1cNuCWteVFnmq20cq4ZYF8w982/tPNwOu7Vo5WDpuMcgn/J93VXR48xf7SA7iw0Np /w3CX9PM7yWlHT/eGFQlAmphVUoqmEw= X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 16D2140078 Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=h31g6wxl; spf=pass (imf01.hostedemail.com: domain of cmllamas@google.com designates 209.85.216.41 as permitted sender) smtp.mailfrom=cmllamas@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: j1ehnop9fiqj1zgfqxf4q6tgh76cgkg9 X-Rspam-User: X-HE-Tag: 1662668911-113196 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: Hi, I've received several reports of a mmap_assert_locked() BUG triggering at binder_alloc_vma_close() in the v5.15 stable tree. This makes sense as the following two commits were recently picked for stable: a43cfc87caaf ("android: binder: stop saving a pointer to the VMA") b0cab80ecd54 ("android: binder: fix lockdep check on clearing vma") In such commits mmap_asserts are added to binder_alloc_set_vma() which is called back from vma->vm_ops->close() and file->f_op->mmap(). 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 undoubtedly it leads to the following BUG: kernel BUG at include/linux/mmap_lock.h:156! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [...] Call trace: binder_alloc_vma_close+0x14c/0x150 binder_vma_close+0xa4/0x184 remove_vma+0xa4/0x108 exit_mmap+0x320/0x424 __mmput+0xb4/0x2b4 mmput+0x8c/0xb0 exit_mm+0x51c/0x6c8 do_exit+0x488/0x1bf4 do_group_exit+0x118/0x270 [...] Note that I have removed such asserts from the binder driver here: https://lore.kernel.org/all/20220829201254.1814484-5-cmllamas@google.com/ as a random driver didn't seem to me like the appropriate place to validate the mm stack locking. Since this patch is not going to the stable trees, the asserts still exist in v5.15. So, what is the proper fix for this v5.15 BUG? Should f798a1d4f94d be picked for v5.15 stable? Or should binder be fixed instead? Thanks, -- Carlos Llamas