From: Linus Torvalds <email@example.com> To: "Kirill A. Shutemov" <firstname.lastname@example.org> Cc: Hugh Dickins <email@example.com>, Matthew Wilcox <firstname.lastname@example.org>, Linux-MM <email@example.com>, Andrew Morton <firstname.lastname@example.org>, linux-fsdevel <email@example.com>, Amir Goldstein <firstname.lastname@example.org> Subject: Re: [PATCH 0/4] Some more lock_page work.. Date: Thu, 15 Oct 2020 09:44:51 -0700 [thread overview] Message-ID: <CAHk-=wgNooZpC8G4=0dB-OBT5PYuv9d=sqzUXS9Ea_acjrAi_A@mail.gmail.com> (raw) In-Reply-To: <20201015094344.pmvg2jxrb2bsoanr@box> On Thu, Oct 15, 2020 at 2:43 AM Kirill A. Shutemov <email@example.com> wrote: > > Okay, I see what you propose. > > But I don't think it addresses race with try_to_unmap(): I don't think it needs to. Remember: the map_pages() thing is called only for when the page tables are empty. So try_to_unmap() will never see the pte entry, and there is nothing to race with. So sure, it can "race" with try_to_unmap like you say, but who cares? The "race" is no different from taking the page lock _after_ try_to_unmap() already ran (and didn't see anything because the page hadn't been mapped yet). IOW I don't think try_to_unmap() really matters. The race you outline can already happen with the "trylock()" - no different from the trylock just succeeding after the unlock_page(). So you can think of map_pages() as all happening after try_to_unmap() has already succeeded - and didn't see the new pte that hasn't been filled in yet. I do think there is a real race, but it is is with "__remove_mapping()". That still happens under the page lock, but it doesn't actually _depend_ on the page lock as far as I can tell. Because I think the real protection there is that if (!page_ref_freeze(page, refcount)) goto cannot_free; it that code sees "oh, somebody else has a reference to the page, we can't remove the mapping". But it's entirely possible that I don't understand your worry, and I overlooked something. If so, can you explain using smaller words, please ;) Linus
next prev parent reply other threads:[~2020-10-15 16:45 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-13 19:59 Linus Torvalds 2020-10-13 20:03 ` Linus Torvalds 2020-10-14 13:05 ` Kirill A. Shutemov 2020-10-14 16:53 ` Linus Torvalds 2020-10-14 18:15 ` Matthew Wilcox 2020-10-15 10:41 ` Kirill A. Shutemov 2020-10-15 9:43 ` Kirill A. Shutemov 2020-10-15 16:44 ` Linus Torvalds [this message] 2020-10-14 5:50 ` Hugh Dickins [not found] ` <firstname.lastname@example.org> 2020-10-15 2:44 ` Linus Torvalds 2020-10-15 15:16 ` Possible deadlock in fuse write path (Was: Re: [PATCH 0/4] Some more lock_page work..) Vivek Goyal 2020-10-15 19:55 ` Vivek Goyal 2020-10-15 21:21 ` Linus Torvalds 2020-10-16 10:02 ` Miklos Szeredi 2020-10-16 12:27 ` Matthew Wilcox 2020-10-20 20:42 ` Vivek Goyal 2020-10-21 7:40 ` Miklos Szeredi 2020-10-21 20:12 ` Vivek Goyal 2020-10-28 20:29 ` Miklos Szeredi 2021-02-09 10:01 ` Miklos Szeredi 2021-02-09 19:09 ` Vivek Goyal 2020-10-16 18:19 ` Vivek Goyal 2020-10-16 18:24 ` Linus Torvalds 2020-10-16 18:24 ` Linus Torvalds 2020-10-16 23:03 ` Dave Chinner
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAHk-=wgNooZpC8G4=0dB-OBT5PYuv9d=sqzUXS9Ea_acjrAi_A@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 0/4] Some more lock_page work..' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).