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 77681C7618E for ; Mon, 24 Apr 2023 23:11:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE6756B0072; Mon, 24 Apr 2023 19:11:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D96BD6B0074; Mon, 24 Apr 2023 19:11:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5E8E6B0075; Mon, 24 Apr 2023 19:11:07 -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 B55AD6B0072 for ; Mon, 24 Apr 2023 19:11:07 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 828DA1402C5 for ; Mon, 24 Apr 2023 23:11:07 +0000 (UTC) X-FDA: 80717832174.24.90ECD2E Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by imf30.hostedemail.com (Postfix) with ESMTP id C26318000C for ; Mon, 24 Apr 2023 23:11:05 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=YNtSLxRH; spf=pass (imf30.hostedemail.com: domain of cmllamas@google.com designates 209.85.210.170 as permitted sender) smtp.mailfrom=cmllamas@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682377865; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GcIY03WA/1a1dnCGs26HGTJ6MXmKGqXJgbmrj5s6HYg=; b=VV6xiAfXFX9LwiOtaCrZTqWhPtz972mzxEt+EfGg8mcvWFd/3KmP4RMiMCX47CFiGNNuCq 1iPi47ZXvqS1xBSuz4rgA4OLsd8Ohj4G8V4m5tNjzS7IWZcepIFDXTx0Mv8MyTajaDo+db V8wMRwOi9728Rr+9R2jmxF3lZDsb+jU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682377865; a=rsa-sha256; cv=none; b=x0ccNCzLjmyRRY50AW9b21V9FvK4iwRUxQ+mI1ALqi9Mtq+nnLZ/7CG63hPM2UA7RhxlYM h5vy4qv2Twb9OAXszEQ1B64UcMmwhaOitNdAKqaws6STuZ88k1aShBoLbtrYCJjwwVztGI kDdzw5fn8Pj8IrZbOv4/TS0oeV67o4I= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=YNtSLxRH; spf=pass (imf30.hostedemail.com: domain of cmllamas@google.com designates 209.85.210.170 as permitted sender) smtp.mailfrom=cmllamas@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pf1-f170.google.com with SMTP id d2e1a72fcca58-63b67a26069so6843064b3a.0 for ; Mon, 24 Apr 2023 16:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1682377864; x=1684969864; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=GcIY03WA/1a1dnCGs26HGTJ6MXmKGqXJgbmrj5s6HYg=; b=YNtSLxRHpIrd2F1oEkhRs5nLfVvO1m5pzIyLCVLCGvlxvzKBosPCqAGbM91clf8d9E ADMl2lPrpsO/4NM0Xz65Wi4dNQzzEh+Rs5N4538RW9Oq9Zoyn8BBKjT6nYad+iWyI/uc 0Vge26ludT3S25KS3GjWnzFqyriVxYrYYEueCG5ierqAZdc8844sBNH9uwnyg1BCJ5lF DvmjjB0/Tws5reubfG/qf75OHbsG219Ai7zGQhjeePnQPNg6xOMy4x3YdCfuk08azT9B F9Jj8oBGfFzGU/95tZf/HGp5X4FYNG4xExLfResLnjAdxVGwAuxiivy1Og2G8i/xzZT4 OWnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682377864; x=1684969864; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GcIY03WA/1a1dnCGs26HGTJ6MXmKGqXJgbmrj5s6HYg=; b=Fg/siLjwtcaH77jrvArgMGzgpOBCQ/CjB6Q7MRVU7vTAmtz69rLg1IvOuTZT9cOJjx epL0xBd+/9r5D4fX6WaZ5aSwmJ0KdmFUfd1n7479KBiiWD3cqi0QdRvRTJlvIgr9T8Zn OpGyJLbpIKFkDovVMRtWRWJIgsQSfptvi7hOXA/jTGDGs8FzTLVkNRnfgIaxfWdtK89W bT7/mg5SoIp/mHSC0RMMyyRcdFO00AOCnCWV9UYcmRymRUdh3iQ4fnq/RD0MGxeSLV7I 6imGuwP4g4vRX4TpQLjGPBMFt6SSsFs2MDn6iGLS0L82KBfaHEgQwG4x6caFOflpjiZr NaBw== X-Gm-Message-State: AAQBX9eDcgJ4ki+7hhqztn/0CnAhtz8D5OVx3leaSe188WR2sCmVV3Zs BT2AyD7SWl9dM6lSyFnAqLzI+Q== X-Google-Smtp-Source: AKy350bOSAbyKbPH0if2wW9knipI29UE3wDfYgfk8VNgx8M/yWvwPZIgYkWGBoBFXLJtVy4SpoPQAA== X-Received: by 2002:a05:6a20:9f99:b0:ef:ef3d:6166 with SMTP id mm25-20020a056a209f9900b000efef3d6166mr16094294pzb.32.1682377864374; Mon, 24 Apr 2023 16:11:04 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id u25-20020a62d459000000b0063d3801d196sm7830362pfl.23.2023.04.24.16.11.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Apr 2023 16:11:03 -0700 (PDT) Date: Mon, 24 Apr 2023 23:11:00 +0000 From: Carlos Llamas To: "Liam R. Howlett" , Greg Kroah-Hartman , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Christian Brauner , Suren Baghdasaryan , linux-kernel@vger.kernel.org, kernel-team@android.com, linux-mm@kvack.org Subject: Re: [RFC PATCH 2/3] Revert "android: binder: stop saving a pointer to the VMA" Message-ID: References: <20230424205548.1935192-1-cmllamas@google.com> <20230424205548.1935192-2-cmllamas@google.com> <20230424223419.6n2z72mocgmcj3aw@revolver> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230424223419.6n2z72mocgmcj3aw@revolver> X-Rspam-User: X-Rspamd-Queue-Id: C26318000C X-Rspamd-Server: rspam09 X-Stat-Signature: qubdsfi8mx4tw3i6ubq6edsqhjxe36j8 X-HE-Tag: 1682377865-631154 X-HE-Meta: U2FsdGVkX1+i0iNAoFyFtgcJZ75UBj1iTz8UuR283bc0Ojz5Dy6d0cAML4KitoqXwb3YvHnLB6wdYXahuuSl4efd4eK1FiZBf2nljb+M5C6VtJeKMPntI5pY8VbW8kq+pDzA0Lbxsw2n2MhPqazrsJ7ggkIWXKcynLo5aeHalOtF1/i8nqK1LS4Vk6VLP3yNDiRpkpJ+0eA+Jw57n8u4rKchfWTgMLz8todBHCr0JrhYnt1j3zbt6Eq1K0jijiNtiRHAGhWIQqLAtShC1yMSB/RCDTYiDrDrQBC5G5o11c719xrvf/MgQ3tRQEt80mxWonME+Mv3oDN3iOQxuSVjPTD8i2tBOrmnCDONG63Mr9bDRzwtaC7XrnDGXqoJ4rSGtn4n3DVL2B5TnJYnqUaLtPXE73glyr0n6Ue1zP2yVMQqEHPK9cwtCFXLSxFctGIJMxDJGS8AdZPIfI+io/aBMSDLos0tTwqAp17u8IbDjlLKszq+ce5gieTRJNbF3aaVcYl9xTpTEg68OHkhKL0NxjUfwQIAAdVqSNNqB902sBY6xjMSceNIZ2vZDHiblKizMTRraFhiRW+9oe3TnpOxLHgXUgzzC/Yjw0AWBy5n+spu+gYiRq9UIE7EvhQA6eJzaSJXBntQcpNN2xIvXt1TLkyq5hx/MxpGcfd9p7fMZa1IF4h1+dN3gy68Sb2Qgc5zJzF9XhhEmdCba8EKAIuPLvHukm4+fGH4GfKLPovCEqft4hSHw/8DQ7hLk/uc4jY8OwzRKOg5feQV3ZBIeCcLYVbyDK/Uzazte76PKHxtiEItB6tWkB9O0OpSC54Df8Kit2wpg4HvfZvmgFnN+L4REy0geBylDhiOFykZzMFj/cKtyX7F9gsrquM5Tc/HEiSWSvdgQG4hZ2sXkAczey4cKPNvu3bNrgm9hq8ZmZGrl02FPf9ZYkkXJidSGSrV+XH+Om5ql8LOWndWKK12ecZ PWp83oV1 9WPdQj0KPWlmwWgaGnSFkR0jK4yCJrC57Kn73XadRLRTCXVsrunPmd3mEkiBLBJo7UnpjLnMKRJOlqo8iWWADdsqk1KMDdC2ot/DoGG9iakhtbqUfgSvt+sfXoPAoFZu1EkP9mEy22PPmdPXXSLt7lHesuGRxk80cZshMJ+dLr8AEggpe2x7/qbSnNNbnwP0Uu6gMsGXx5Ua34DKwH+/nUuJkPBpwz+HyRknBWQE3R0Du3YtkrKwJGxLMH4H/6YMdrcaE9T5innjk5OGjK2y/E1uOyzLEmSDkJNfjXns+w+ZmJH1MJgFrbBUU/zulKcuJNxSrY5vW8v2LadWgXXIqzrfHomTdCKtuHiOZDxUFi3nGRJuPgVs94Cku0haDBo38tbDst0+6g9OR1uUclhse6o1bn7NNODZ6U6vq0nIoWcIZ/O9IWJC3MatBZkhAYxaO+rcS 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: O Mon, Apr 24, 2023 at 06:34:19PM -0400, Liam R. Howlett wrote: > Cc linux-mm > > * Carlos Llamas [230424 16:56]: > > This reverts commit a43cfc87caaf46710c8027a8c23b8a55f1078f19. > > > > This patch fixed an issue reported by syzkaller in [1]. However, this > > turned out to be only a band-aid in binder. The root cause, as bisected > > by syzkaller, was fixed by commit 5789151e48ac ("mm/mmap: undo ->mmap() > > when mas_preallocate() fails"). We no longer need the patch for binder. > > > > Reverting such patch allows us to have a lockless access to alloc->vma > > in specific cases where the mmap_lock is not required. > > Can you elaborate on the situation where recording a VMA pointer and > later accessing it outside the mmap_lock is okay? The specifics are in the third patch of this patchset but the gist of it is that during ->mmap() handler, binder will complete the initialization of the binder_alloc structure. With the last step of this process being the caching of the vma pointer. Since the ordering is protected with a barrier we can then check alloc->vma to determine if the initialization has been completed. Since this check is part of the critical path for every single binder transaction, the performance plummeted when we started contending for the mmap_lock. In this particular case, binder doesn't actually use the vma. It only needs to know if the internal structure has been fully initialized and it is safe to use it. FWIW, this had been the design for ~15 years. The original patch is this: https://git.kernel.org/torvalds/c/457b9a6f09f0