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 385D1C0015E for ; Tue, 11 Jul 2023 21:55:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2AE3E6B0071; Tue, 11 Jul 2023 17:55:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 25F156B0072; Tue, 11 Jul 2023 17:55:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1269C6B0075; Tue, 11 Jul 2023 17:55:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 00C426B0071 for ; Tue, 11 Jul 2023 17:55:36 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BF3CFB0041 for ; Tue, 11 Jul 2023 21:55:36 +0000 (UTC) X-FDA: 81000688272.06.CFAF1B8 Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176]) by imf17.hostedemail.com (Postfix) with ESMTP id 06D5D4000E for ; Tue, 11 Jul 2023 21:55:34 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=3M88JkdW; spf=pass (imf17.hostedemail.com: domain of surenb@google.com designates 209.85.128.176 as permitted sender) smtp.mailfrom=surenb@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=1689112535; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Zb38lIsRWc2jr0KHsHaXSR1cwn4iPKJmWNpSW/nVc2Y=; b=o2UVlUu5Icaats8fcNV8sFtJUXBePrAqxoPXam+pxat4XQgzXmpzyc3nPrU5MtsXMUwPO2 qUz+OhCYE33oRAHlpY7WpS6i9Okrwtov/ijoTFQe3PgYN6jZ2CF4nF5cip65r8UmPcBmxj aIEMvf9BDMjr24+S817qIXEU4aLGaHM= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=3M88JkdW; spf=pass (imf17.hostedemail.com: domain of surenb@google.com designates 209.85.128.176 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=1689112535; a=rsa-sha256; cv=none; b=P4n5ENe7o5lp0EQcWZM8+Y4AHD08qlwhD4SgY0mIysh2hsEOx50oVGItSXzwnR5BURlmea lUABP8UpZZINm/X5ZkCpfDZB612Nvf7nzvIBVOJ4A2fPLosURm7shH6oVMgle4tmn6TSqe ItOgJq4maTboKR2IPEcgIJPTVYJMgl4= Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-57a8080e4a7so31958597b3.0 for ; Tue, 11 Jul 2023 14:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689112534; x=1691704534; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Zb38lIsRWc2jr0KHsHaXSR1cwn4iPKJmWNpSW/nVc2Y=; b=3M88JkdWK0eHIQMHnIFjUtWmZ1hEO6IKYAxof03E9c6jjYFUTqB7WqY/SKp9/+CZaf 9DHPmvrj/eMfAV/Gs9mFRl/GBY4LCqCvnAtdpUaYxecGIqnqdfx5nONuue3rGvv35jcN 8LNmvyrKlD5m9keV7Rj+v+zjDT94dKd9rE2ZQFixG1d2gNDMX542DIuKqnTbSTwPVlOO hQc5miFG41utcWho2VuXBxSTBUufWbiKaGIkN6kXEH32SbzGhE2wM67+CcJ68dXmifLL CI+qRXebERdHJDC9sjJ42EyiU4pXSlKN2c+HycnqFA36Eow75d3FkrrvDHc/BrMPtvJw a9eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689112534; x=1691704534; h=content-transfer-encoding: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=Zb38lIsRWc2jr0KHsHaXSR1cwn4iPKJmWNpSW/nVc2Y=; b=SI782gzxADoUxr1TiwMmzolJKBoNOHSKXoe7OHeweOSS1BuL10R+1acWOmL2Tky+xf sE9xfDmJyCIMGsel+ka4lKuhtHC+/HcuzBmEXJF0wW8lezf5ezEJtWtJZpLkU2hW2Chs 3U5ILaC5hGeU6ZixiiLtL8vYZ1X/Ipg3/GLs21WvLwdEuLJ7LhnYdt8L36idXlJQ67ht cPbjXyY7u3OBfKIkMHULO0oauD4Nv0suhEbC7eGg5iuuHGT6qNt1N0RzbmBnMFvOgDpk jzxlB6WjUzXgLl7zO86+SJGucqYxl1dn9HiA97rOyCbiKEryam7pRz/doEeX+gajruls PODQ== X-Gm-Message-State: ABy/qLbAkWr5kO7ZGZ4O/CFNfKV+HYdE0OcNJvuiAIZgqmlER7UPMRw9 izRHu+/0uLYoTpe1CO6Vgp7QG6lm8UkwwSQS3xiVRQ== X-Google-Smtp-Source: APBJJlEJoPiSSZm2nCk4QXI4qS65+EhXv5wAZxnorvPcJaSAFjRa7HRmsIE6MPA3ra1ibb/HlBZu96lSNAwIofoIGVE= X-Received: by 2002:a0d:db0a:0:b0:576:fc3a:3ef5 with SMTP id d10-20020a0ddb0a000000b00576fc3a3ef5mr16401731ywe.47.1689112533889; Tue, 11 Jul 2023 14:55:33 -0700 (PDT) MIME-Version: 1.0 References: <9704a138-60e6-4ede-91f0-844e1df2ad84@moroto.mountain> In-Reply-To: <9704a138-60e6-4ede-91f0-844e1df2ad84@moroto.mountain> From: Suren Baghdasaryan Date: Tue, 11 Jul 2023 14:55:20 -0700 Message-ID: Subject: Re: [bug report] mm: replace vma->vm_flags direct modifications with modifier calls To: Dan Carpenter Cc: linux-mm@kvack.org, Andrew Morton , willy@infradead.org, "Liam R. Howlett" , Laurent Dufour , Michel Lespinasse , Jerome Glisse , Michal Hocko , Vlastimil Babka , Johannes Weiner , Peter Xu , David Hildenbrand Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 06D5D4000E X-Rspam-User: X-Stat-Signature: 7zkipw5ss344998p4qcdxb9jdf43q7qb X-Rspamd-Server: rspam01 X-HE-Tag: 1689112534-911580 X-HE-Meta: U2FsdGVkX1+4OTAlB9f+M6a08LvWvXyvqfhdRNiePm3/f88VcIFViQ13qTXtHet4OGqzdECkYxLwWZmErq3DesmPCJbv1EKj0+bbSGOvzbwcC8Kq/XVWiysSGeW8jpVdj9zwEi6eBvb8PEZDohYCLsUbmAmIb4Y6kVqtbcNPrkEjAvI2khPVsM/aWviMHoaCUTmFwPPAvP7MlIpfIGKj1DaoQvrhJc09L/Xhdbf0Gt0Hh+EEvhHW+bBz7mM25coHmMb2k9lp7c/Bp5ZuN/+5d9Kk8xZFMcQAaO71i18TJRlQCn7ZcvCNtw90qMClVoGY1CdtcUYZ/wiAQ7T0OLfZgPngaiYPWqVtkR+eLyN4Gojb162zJRtBpAfNYIaPO0KE3OOUcHvhws3cRVk6ZgMPgmTZJVTEdaaVLB5veHzdwUqrume/z/Jss/+OHm38i1Rglv7VV9S5BPrEKWT/sWwzkiUUNhrMiZTokWS0V7yheoyBlHXVELhL1IrC7//I3LpqwF/4ZWE1979aJx/E3vXyozeueoYIlclYe4gnIQbDfYSWJIPQnP8Ttq8Y/4YJ1QNSSIBastRZkfgChHOU7/4SFoc6mC0/JieOttzGCaE5dPU30wo3VM8L06obZcEwzUSMTTyvUY1K2lDwFGgF2g/2dq7T19z55AFIAin/TuxgMp9/Bed6g6A5lDRHy/WOogN9QE2f8NOvSJNr/XpMYr0PphWeF+BcWNaJxnblYzicw0Ls6kFlslxmuFQc67rDhwb+AmFvs7UlKre3PJWjS2CQbOF3xbxZqb9YCqSE7PKrnVbNkF4n3JwsFEHJbj7nA4PVwaEvaqRpw2Pklaa7Ko8yVx2pB6Vl/DeUyl0UxuUifC/hWbRuLITtxPKTJAtoxnEArKABKtk6XH2Fzpq9b7KL1tJwExFjw32f2twBo16CZjukAzMrAVjb97jLe2/UELLso55j7MG5Zs0bmT0wmc3 HFyxD0Pt En9bzfBe54sANXTYzL/0u2awt84WgH0OL0b4+fDs35OcyMEJGMWATXIBVaSequIlVWSRCFtAPQuIEjUkGTKyrXPwMKZGTY3zVY3sETXFOBnn0oZYZf8x0QXfk5c2/9i2a/D644fp7v2yitIJVVVRLpji5L9p5gGaYLN2shl55CuGSxa4da8Oz2gnCmZFc33eixj4Q0Xn3NfyJd3tuJjy7GRlh+Rbt55Jnq8ffEQaW9QK/838l4T8jXquMkjHv/H1LmyOfoC6e1SC8t0EMuNyRKSRAg1ot8id8tUbCJOBesNxP+zzNH28DxgPCF1N7NxEwIc6R5Zb8rl+tIhs= 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 Tue, Jul 11, 2023 at 12:21=E2=80=AFAM Dan Carpenter wrote: > > Hello Suren Baghdasaryan, > > The patch 1c71222e5f23: "mm: replace vma->vm_flags direct > modifications with modifier calls" from Jan 26, 2023, leads to the > following Smatch static checker warning: > > ./include/linux/mm.h:729 vma_start_write() > warn: sleeping in atomic context > > include/linux/mm.h > 722 static inline void vma_start_write(struct vm_area_struct *vma) > 723 { > 724 int mm_lock_seq; > 725 > 726 if (__is_vma_write_locked(vma, &mm_lock_seq)) > 727 return; > 728 > --> 729 down_write(&vma->vm_lock->lock); > 730 vma->vm_lock_seq =3D mm_lock_seq; > 731 up_write(&vma->vm_lock->lock); > 732 } > > The call tree is: > > gru_fault() <- disables preempt > -> remap_pfn_range() > -> track_pfn_remap() > -> remap_pfn_range_notrack() > -> vm_flags_set() > -> vma_start_write() > > Before track_pfn_remap() and remap_pfn_range_notrack() would just do |=3D > to set the flags but now they use vm_flags_set() so there is a potential > they could sleep. Hi Dan, Thanks for reporting! Looks like the page fault handler is modifying the VMA flags, which has to be done under write-locked mmap_lock and I don't see that being done here... I wonder if that should be allowed. I'm CC'ing some MM folks to check if this is a valid VMA modification and should be allowed. Matthew, this might be especially interesting for you since gru_fault() handles file-backed page faults AFAIKT. Back to the issue at hand. If such modification should be indeed allowed then the simplest fix I think would be to add new remap_pfn_range_locked() function to be called from gru_fault() which would use __vm_flags_mod() instead of vm_flags_set(). __vm_flags_mod() does not lock the VMA, so would not have this issue. If the conclusion is that this is a valid scenario then I can post a fix I described. Thanks, Suren. > > regards, > dan carpenter