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 06157EE4996 for ; Mon, 21 Aug 2023 04:55:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E43C900004; Mon, 21 Aug 2023 00:55:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66DA28D0001; Mon, 21 Aug 2023 00:55:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E729900004; Mon, 21 Aug 2023 00:55:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 35D1E8D0001 for ; Mon, 21 Aug 2023 00:55:25 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id EA775C01BD for ; Mon, 21 Aug 2023 04:55:24 +0000 (UTC) X-FDA: 81146898168.04.0DAC808 Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) by imf01.hostedemail.com (Postfix) with ESMTP id D288840017 for ; Mon, 21 Aug 2023 04:55:22 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=T0gz4gUT; dmarc=none; spf=pass (imf01.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.179 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692593723; 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=bBPIa0Y0nf44GPXwWTAaO4yGtE4FDjY8r9GXV2YK4UU=; b=5q4wi1C7bNII0JzTqK+JUMy9gcwLFIUBDaLBGYb6zm+VR8oTtFQ7Gu4LVnOpJRnw3Ye+Qv rblnJF+qboG8d9RA2su9bMAMZ3wmkpwEm5zsrIL8OhMCdOyeJxbHOBsYJJQYIsr28wM2dj PanT5a9fghOrw8wY1LugMgon4G1w6Kc= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=T0gz4gUT; dmarc=none; spf=pass (imf01.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.179 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692593723; a=rsa-sha256; cv=none; b=Zrpq8xseWFNyRCJmjYc9Rdn+yrqXt20YwAh1TTosBrdSBJ7u/bUpJdBBcj41vGs+6vfXtU rDLpT+bGngshull/Yq7wVqJeHqRtwEEBvrA7PnsoLfkBj3paA2NmEOfI7rugVgs+YgL7hj 1sOWPEg//weeSHBaM8BZGwpvblgPjKE= Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2bcb50e194dso16522281fa.3 for ; Sun, 20 Aug 2023 21:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1692593721; x=1693198521; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bBPIa0Y0nf44GPXwWTAaO4yGtE4FDjY8r9GXV2YK4UU=; b=T0gz4gUTApxGAH1pTeA2eFV29EqZD07oYhbvzgVYvn3oDP7QcSZJhspwirBZOk4Hir hoWUa9ReKe6H1h3jx8LcSsEHKnFKqcqEFDIqSNv56QGF65Vgg3GNIwWwE7xKZaCflFHt 7a43VWcG0d7mcafYGJy54/bfrBGzTxEQN3juk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692593721; x=1693198521; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bBPIa0Y0nf44GPXwWTAaO4yGtE4FDjY8r9GXV2YK4UU=; b=K7SaJ97Ot2841v78Qs9Gn5AonR/zwzQKt1h/WoS8JrUGGX1dPn8kk/UymY+M/q0Tv+ 4jsZ+6mPTVU8qG2itYGltfNefjKCp1GcfnO567L+TOW4avGti0Q3Q146MDCpAD/Xv4Ua 5bTxL8eGqVEXeoM0shx4Oi0WzOu44VJYmlyo0VpSaahWuxklL90qf4HF3ZJbKICKaAfo 8wVhJaXwfRfY4/rw8yMYBGIsNhE6+A94IvsCopGQlptibntuDNO/8zGYVrT6tgl6dN9o 1k00Baw65WIUw2aLDazW7kTtE4WzBvdy3fVVtzoM5LF/tBdKJ0ZUeaPisyMKQ8MwYRuC XpEw== X-Gm-Message-State: AOJu0Ywjg2JzXTUtE9Y00ABAYOSUPa8Pe1WhFkVGwGux7vpKi56HyTzw Y/KKOOrVgp7ft1YGUfo9vLAgslYzgJsE7pxV1qtbpQnC X-Google-Smtp-Source: AGHT+IFRe0szdqjUSqF1gzTn1fKSFx3ZujiG35kdNh9TIcPM7YHaXpOzMYt+MXtF5cmIIFwpf3QX/Q== X-Received: by 2002:a2e:b710:0:b0:2b6:a3a0:5f7 with SMTP id j16-20020a2eb710000000b002b6a3a005f7mr3982271ljo.9.1692593720798; Sun, 20 Aug 2023 21:55:20 -0700 (PDT) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com. [209.85.208.182]) by smtp.gmail.com with ESMTPSA id p9-20020a2ea409000000b002b6c92fa161sm1999469ljn.61.2023.08.20.21.55.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 20 Aug 2023 21:55:20 -0700 (PDT) Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2bb9a063f26so46726341fa.2 for ; Sun, 20 Aug 2023 21:55:19 -0700 (PDT) X-Received: by 2002:a2e:9b49:0:b0:2b9:bf49:901b with SMTP id o9-20020a2e9b49000000b002b9bf49901bmr3580293ljj.6.1692593719477; Sun, 20 Aug 2023 21:55:19 -0700 (PDT) MIME-Version: 1.0 References: <20230820104303.2083444-1-mjguzik@gmail.com> <20230821011303.hoeqjbmjaxajh255@f> In-Reply-To: From: Linus Torvalds Date: Mon, 21 Aug 2023 06:55:02 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm: remove unintentional voluntary preemption in get_mmap_lock_carefully To: Matthew Wilcox Cc: Mateusz Guzik , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: D288840017 X-Stat-Signature: x1fn89r468qdf46emgyx5ddt64zq1z1y X-HE-Tag: 1692593722-121902 X-HE-Meta: U2FsdGVkX19SUCvD4mbYodskalZAF9380XMUeZ9RgE7gLqOliKB4bhYkIxlZi8bk2pEeF1yUmCkVPb2XC4JC8t80AJW0vhvpwqs6g0zrsVOEg0oC609ERk1k9euFMgEpBVVa9kDy9awyAYzFZ83WQekZiSu9tN9+Wa5YZzV0MpB4PEHJc/WUrX/Wf6A7qIPisHKEVieDx0J6usGkZTu+aQ8FHil6kRl8JJ4V2O4IVC7IFBzGZTf+u7O+o55b5K9TDbzBy084Vv4Zc+ZYm8Hod7U0Z5mknQeV7E/m/9k9nufuvcuvnylPrPIcKoSJW3yU6DP0kZuPpIF+PRU2Edd9IrH/AnoBQCD3z4isrXw2eW9zjcTIEqaiZ+nunGLEM/TXMr7h0d+B5hUVXfQA1J5kq2aVCBj35VQvG8rP0ETNGzVBS0TFnGdLHBR++HMiWmQzXgMnveOFV5rUVuN+i57Jo8rvK5vhYHtGQNDt5wi3ObCEapHVzAr4x40ts6RVcbEQnxQLoJ/Z0GupzriIH9aMGdH5BiuqH76f74lz9PGKEV5OHQH51oe4eGjV1ktnV3nlhT4ywef0iYmcGiWMiRP+Rg9wI5CfvnjT6qiWRmqW5K9m9XmSWjh/a/t2IKKz/sClgC9Z8LQB3n0nXWx0VhWQOHfPMx7mIA+ecNXiP3izgTkRAwyafszNvQlx5zuVzMneIVcpXij9LbT+LEI+uRSFwBuXOfRR3ItcAdMTZfmrEz10EwR11WiyGhpi9uDT8dZ1GMCN4f0eNMCRnSz5aeBM03CfRuh2TAkppcewGG/sDGEKSc2caCQP6I6qOr3E/Hk4DkeEc8KDlPqyAVIsUsYlk1tmkOGj7DYjqcP2zzRdGnBmcDx2F/GTB7vcySJFedcEwEAOoVOLhQoZJ3ngZ/O1ZuM/wQvWxCGJQRdyfj6/+ghOuMib/8+I8FSK0HQzXHLTgKDJsEvLxPA6f2JNKmH 7P9MlJmQ acXag4tHtFAGHQxbLyCPZNhCJaYLFnD27zQK5boLTOZ9//y4lvJMwWpGSihA7eWwWfRancZ6hDD7rTmxsOxdeVZbKK9XVq7P4eulD3Ew7kX+2SxSkEtW4Y7UVv9Lj64M6/qimSD6S7AfJfjQALu5xdHjQqgjV6+VCXJOQlGPd5Kf5aBRTmp0Nw1HGugkTaG9DiUVKZelhcfAo3O/lFDmVm2xrFUJ08hDO26gpifMYZu/RpF8Rp0FyticTKj+KbfaWl0DE6ajYBJ64J1h0GoDGTnWOyqHancFYRHhMC9Mb6mhMIK499hJC8sU6dC1BM3Ddjet1sPM7vUpwCRN9vKILMGFVYk46IjiVoNnqzTm8pWXxRx8JQ7HAsO0L6fL3J75yMKKDShiyS1ISJGNPmquZVMU8wpZOx+7HpIO2Eu3wDyotQBTnj+Ff/R9rsU2SlCis8HxO05XZNjdm3IrFzL0buJ1G1J4A0MreRgt9HYJslttW0UFD8dkXE8CQwGNM95x3S9x/7Zin8dqU9yLTAVUbMdySZE2B1P4UO0NItPndho+vzb9ce7x96z2wr4crxM0PTkQx0/kSVcbO0NuRbIndEPl8rHFsZFUt/lRd 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 Mon, 21 Aug 2023 at 05:58, Matthew Wilcox wrote: > > The might_sleep() is clearly safe, but I thought of a different take on > the problem you've found, which is that we used to check need_resched > on _every_ page fault, because we used to take the mmap_lock on every > page fault. Now we only check it on the minority of page faults which > can't be handled under the VMA lock. But we can't just slam a > might_resched() into the start of the fault handler, because of the > problem you outlined above. Bah. I decided that there is no way the might_sleep() can be the right thing to do inside get_mmap_lock_carefully(), because the whole point of that function existing is that we might have a kernel bug causing a wild pointer access. And that kernel bug would be about the subsequent oops, not the fact that we might be sleeping in a bad context. So I have just removed the existing might_sleep() entirely, because both the warning it can generate _and_ the voluntary scheduling point are bad things in that context. I do think that maybe we should then re-introduce the might_sleep() in some actually appropriate place in the page fault path, which might be 'handle_mm_fault()'. But I think that's a separate - if related - issue to the whole "this was always the wrong point for might_sleep()" issue that Mateusz noticed. We are generally much too timid about removing old debug checks that don't really make sense. Linus