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 02843EB64D9 for ; Wed, 12 Jul 2023 07:35:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8FEDC6B0071; Wed, 12 Jul 2023 03:35:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8AF886B0072; Wed, 12 Jul 2023 03:35:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 74FEF6B0075; Wed, 12 Jul 2023 03:35:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 621FD6B0071 for ; Wed, 12 Jul 2023 03:35:38 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2370F4018F for ; Wed, 12 Jul 2023 07:35:38 +0000 (UTC) X-FDA: 81002149956.16.7941CA2 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf01.hostedemail.com (Postfix) with ESMTP id E1A3040012 for ; Wed, 12 Jul 2023 07:35:35 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GDKY+QIw; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf01.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689147336; 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=adntLV6fU83oiuUcohmHv0kpG2e85lv4uYHosruVPps=; b=Pcp1K04SwTRCGzJuF+cJhQCJM6V7odMBo7g4Bm5CBqXFZ+qpeUDkyaNZhCwq3aP5ZovjQ/ n+a8zSruV5HIpfaATXHdEu3y4NkAPYhQXwl1w9KRhkWNBU4sV89WK/pbusHf8nX0fxwBwO R3aV5SueVqCVqntKvMQ45cwbgSzUNAg= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GDKY+QIw; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf01.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689147336; a=rsa-sha256; cv=none; b=6QjJjgSaT7HJrhCDVyQH60U+24SO098C841urf9N5rby63ho8t3tLabbspo3dmo9A2Zwbo Lapl4rBFwiFonMCjf9Y2jQOYSjgGdXPcSFcrtFweAhGj5FgFno3zGCfcwEh/I73N9rINU7 aoz2B9RV59oHkURI8lxphov9orhz3SE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1689147335; h=from:from: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; bh=adntLV6fU83oiuUcohmHv0kpG2e85lv4uYHosruVPps=; b=GDKY+QIwLaoNLXLNQEsHASX7Dt/amuCzjzifTmzezrPf4ziv+iA20n3aWANoRy5kQ3sKmD QN/ke+g7k3HIIDb2sOf5Lip9zUSPFP5bArE3bxLIEnqYVJTmonTQ+cDx71cssWaQJiMy1K +k+LtD/uy4WpCqpLSYuMyeBmLa9wSEk= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-672-8tZANYoHMNa1tcCj5CC1PQ-1; Wed, 12 Jul 2023 03:35:34 -0400 X-MC-Unique: 8tZANYoHMNa1tcCj5CC1PQ-1 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-3fa8db49267so41482265e9.3 for ; Wed, 12 Jul 2023 00:35:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689147333; x=1691739333; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=adntLV6fU83oiuUcohmHv0kpG2e85lv4uYHosruVPps=; b=kkTtKPxs/RNl69OfXFRQ2wCDiOMbTdCRgEFJqVqO7X+P651WWauhKrTXRRyeOo8Tl0 x0qk1CFrchzAtF21yMKhPkpVxa4KkEtDFnW0eIJ+02ZZgTlXbTaSeAj6yAfbw62lLP0q 0IQeWoHV52XDUCYSk9O7Hx+9e0DCXnm+ZOaKRrrjg3jtEGZIc9lLXagXrwm39ON0f/TT wpWxgNvMQX41VofJ8te/kR26bn/909raGz7OIxhlL6N733t8VBRa9C03+kSOiEWMhwsg iT0PD8yVDXT7sEox+/sZzzN+7lsA4F5MyfK/r38ltAV7u8oMeUgu3e48kI07wu0lGseS SyUg== X-Gm-Message-State: ABy/qLY3LRJzM5r70TpOhTY77eaVg62z7KvJcy63ljOJc3VwdqpZ7Q+c SDbjvj4y7v3eAcvofxW+0jp2PYNTQoDhFEfHv9WvORMPTB9iHZEDjT6/aIfhw9DXDiJyQ1h6tuM NJ7u+z5XTujg= X-Received: by 2002:a05:600c:220b:b0:3fc:85c:5ef7 with SMTP id z11-20020a05600c220b00b003fc085c5ef7mr10705830wml.22.1689147332902; Wed, 12 Jul 2023 00:35:32 -0700 (PDT) X-Google-Smtp-Source: APBJJlHkpG9j55x1R2SA6OzaokiqOeHaSPlWckvZR4f9qv2WJVefyusZs4jKTaji1+9U8XzulQ+pXg== X-Received: by 2002:a05:600c:220b:b0:3fc:85c:5ef7 with SMTP id z11-20020a05600c220b00b003fc085c5ef7mr10705806wml.22.1689147332490; Wed, 12 Jul 2023 00:35:32 -0700 (PDT) Received: from ?IPV6:2003:cb:c707:3700:3eea:ace6:5bde:4478? (p200300cbc70737003eeaace65bde4478.dip0.t-ipconnect.de. [2003:cb:c707:3700:3eea:ace6:5bde:4478]) by smtp.gmail.com with ESMTPSA id i17-20020adff311000000b003143853590csm4243399wro.104.2023.07.12.00.35.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Jul 2023 00:35:32 -0700 (PDT) Message-ID: Date: Wed, 12 Jul 2023 09:35:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [bug report] mm: replace vma->vm_flags direct modifications with modifier calls To: Suren Baghdasaryan , Matthew Wilcox Cc: Dan Carpenter , linux-mm@kvack.org, Andrew Morton , "Liam R. Howlett" , Laurent Dufour , Michel Lespinasse , Jerome Glisse , Michal Hocko , Vlastimil Babka , Johannes Weiner , Peter Xu , Dimitri Sivanich , Mike Travis , Steve Wahl References: <9704a138-60e6-4ede-91f0-844e1df2ad84@moroto.mountain> From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: E1A3040012 X-Stat-Signature: ae7p5y1gar5fkppnmzgh3bkwf83cw5pu X-Rspam-User: X-HE-Tag: 1689147335-118795 X-HE-Meta: U2FsdGVkX191J9ah7nN1w60olPzZ5N9V7IOHegIOzQzy+jMtvjcKt9RSRRKfFtDSl8AHpEU1UQCDxyTPZfIToI4p/8aeZko86Q7taZR0esEkTHc38chCC7Kk9nL3636B56LVlDOz2sfrXUPJqX1DFMkVhA3qaZEgU6uk+Mul5hrA8e2fcmIpBdS9TTkJbj+DPnqHgvzupAqryDBXsCVkYcf2lhXtnqiUc3tPdHgO6DN54mLVxg7mHbKTiKpzdj9SQwDxPnmySZLf/VkrLYfsi50SAJIQ1xyFuRI7TM+lfjJfuz7xxZHsJVHopz9zvU/9BRmaSnULxmDYRuGuII+NUIbw1LSt5iJTQa0lL4THywM4wwFYcC/zUM9qi3hMIYMRljN2jFPQ5TYcor1Tq5GcXStyqiePxmfFyirhZLQYptlRwiNjAbtSIExS8LxLu3evIis7x87LtYNLBLjPfjFTNrW1oVB1UqOo1bu8iuEUyI4EZelGh/h7JvGRsJpH2g2ZlSuVWGKX6VsSTRJkC5UxmM1UjNKkZF1/n24xogaM+LtKHIaVQUsFROoBc/zOWuQWcnoYwbPNmsbfK6rz9QJMTLNo9igV7a/hovomcLzsfZ1dlQp7SxmlIckvsLrrQZ3ZVn+ryQfpcRDCrYbSey67BGdy13CO7Edo0PyXq9rbteP2MtXg3Nw7A0GO2sQI325UgZ1HGNvuAO9cv19sGvuDRavgiobD1bQZgKp+r9sFsp4JznXDVFV90PvHwt4kBrcemjMGhLGlvwp5VhnWBMCdTrkkrGQBYL18rhPqHVVk7nIbPFBdnDw7tfcGB0SJTvkgQKRLyEDj2+fYyAaUy4CpfpoLAiyf2CFCua1gtV1oJcJIUMC4M/4CQgdbFn86RoEp7mJpcXAwRKk+GWnjTQ5yT8LcWxm7mWF1r0d/sDdH5zR57zRxZLk+6OHodeRqAPT2qaHcbOQ4ea+QR+BDMkW RA75tTiA 1/iXc6+W5nmCcH/UPabxNM+1cqqexsEwDzSKKrBuXVxKU3fad7CcOuQcoArdF+cY6FkN1Rp/NfdOyk10telu3/UNlv8PKc6n0xO16z8RFr0wpwbhY2kd21SsP5yaHJQ9GqiY4lCLuATy8b2zf1Pg83mzxZeeB5Vfpd0ZC7otcNM8e0mCCcHaUoSW4EaI3s047UlrqsaM8W6nkZ13o46IYf6bLS0OEiLNQsBHTX5tRrJu0m00V6YetHEvPA0vSQqKMOcV+si0a/+9dW5WrH2PLr9etztLgVXeulZnomr8Tz7m/iFxxwzK5RH5fuMBsdw9IWqwnAHIm5Xl0U3CUSeGXtpFEz6U1gApJfzm4Z696xlGEjNDbk2aMgVKy+d13BFnggcTxGZeV2QEUKx2LCYuIDwaJpCxj9zz9/fOKLcpaWjGiCaO5IaDxqwTEeepkNmrMwdhnlyTPid+6HXQ= 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 12.07.23 01:45, Suren Baghdasaryan wrote: > On Tue, Jul 11, 2023 at 3:21 PM Matthew Wilcox wrote: >> >> On Tue, Jul 11, 2023 at 02:55:20PM -0700, Suren Baghdasaryan wrote: >>> On Tue, Jul 11, 2023 at 12:21 AM 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 = 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 |= >>>> 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. >> >> I don't run the ->fault handler under RCU, only the ->map_pages() >> method. I don't intend to change that. >> >>> 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. >> >> I'm not certain, but calling remap_pfn_range() in the fault handler >> is definitely weird. It's normally called _instead_ of having a fault >> handler. The fault handler usually calls set_pte_at() directly. > > Hmm. Is it weird enough to be considered invalid or weird but still ok? > Also, is it ok to modify VMA flags here without write-locking the > mmap_lock (and without write-locking the VMA)? The fault handler is > done under read-locked mmap_lock but I thought VMA modifications > require stronger locking... > The "easy" fix would be to have something like "remap_pfn_range_prepare" that the remap_pfn_range() caller calls during mmap(). We can let that one set these flags, and then we can later let remap_pfn_range() fail if the relevant flags are not set. It's certainly one of these "always done like that and suboptimal but somehow it worked" thingies. I suspect, because only the first pagefault->remap_pfn_range() will actually modify the VMA flags, that this is ok. Otherwise, there usually wouldn't be any pagetables and nothing mapped, so who really cares about these VMA flags (e.g., GUP cannot pin anything if nothing is mapped). -- Cheers, David / dhildenb