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 78DA6EB64DA for ; Wed, 12 Jul 2023 16:05:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE78E6B0071; Wed, 12 Jul 2023 12:05:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D95D56B007E; Wed, 12 Jul 2023 12:05:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5D798D0001; Wed, 12 Jul 2023 12:05:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id B798A6B0071 for ; Wed, 12 Jul 2023 12:05:02 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 75076120300 for ; Wed, 12 Jul 2023 16:05:02 +0000 (UTC) X-FDA: 81003433644.05.F2D328F Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) by imf30.hostedemail.com (Postfix) with ESMTP id 8527080050 for ; Wed, 12 Jul 2023 16:03:17 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=oFl3OkTF; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of surenb@google.com designates 209.85.128.172 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689177798; 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=/7x0+AW3rOouuj0dxK2+UYQ1lI+Sl1yryuJC4ZCIV2c=; b=I1Hyz81yfP9G0ZXdHbbOV0MCAsC9EGYjBm4nFHnCOZS16o2zUn6ew70OSlc8irlVRrx0/z 3Yhvr+OSvv3z77Fqh4lGuBMBYT3/lE0qrCie3gDQuX55dXyztidFH6pl3q0bn3bZ3e0au6 MJ8HgvyjX26MEQIe8jqL/Q1Gh6IP5G0= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=oFl3OkTF; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of surenb@google.com designates 209.85.128.172 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689177798; a=rsa-sha256; cv=none; b=SS6QfsDkN/cVCwb1nW2e2NzUWMkParDWcJUtugHWsej6Jof5V+LeqHRQMsdDgW6wHI4Gq8 u+bdCkLSjEUormfC1GAuIqsPnXoNoi7TYy1LWFxvrgkxI1D3QqXLAM//rCoFT+NaX2HiFK aFepGQ++We1+d7KTKVX2CECcYPgbGA8= Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-579e5d54e68so81005227b3.1 for ; Wed, 12 Jul 2023 09:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689177797; x=1691769797; 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=/7x0+AW3rOouuj0dxK2+UYQ1lI+Sl1yryuJC4ZCIV2c=; b=oFl3OkTF4AgYseyeBrhG6ETzU08wQ/+OPwsF23HeLjei69HkXRSG9iukUFLD8p/qh2 dYjccdKiUYQt0ZWLZTHEnqNy+pf2XqlkJ7cD5Rf2nF5OM/8YTXw/IuX/GG4rWFzbopiL mw1J7Pud6Z/b/ts8sid0v+LqFbLA3rbL1l2unr4jqjvQrxQtrudM61e26JpSaUAf4rHg uc9z8CzyFhMvL9OW6R/XtBEy2kePiidFf7KHEAFjaqPPeawpuOvzyUcB3FvZa+EUWFnG gGvmRoUIa3KcyxbHau51KgZC6v7xNFKXBiL8BFXp0TX872hsebtruVW9jUJ5tXOsHqXL 8B6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689177797; x=1691769797; 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=/7x0+AW3rOouuj0dxK2+UYQ1lI+Sl1yryuJC4ZCIV2c=; b=ULrZDaCDqmFF1AOWbHS0YwYI4y3DW5XWTJQyfu0WZYXNFWldZxd9kI1iXzTRBS9Knm Qg7MJyo/fF6rsgsNWMjx/88eXg3EQ0hGhl8fHx88T0HkL9HiVkYj+zuyswZDuG+W2SWk ccB0QwY+l7RPqURlRRtVXF6mXtosbzPc5q8f+hLpt0p56qsl3GRUeEk73nbsDj9cEA0R 2aG1nsgfocxq94C2axPyO4rCxBJbOeiHOY+UqF2GWhLUP4ScjT3WWU7VdFno8f8P08Sf xI1+GcWK+to3hpMp8S85m87Zn5N2Yy89lZOQuTZaY4SIMdz1WfKa6PQO4Xs9BX9TP2Xw 0qeA== X-Gm-Message-State: ABy/qLbIZEzBIWvLFsX0FFi/9Qk2M1X1CDFCFM0jcUbTwMpbNuKrX6HZ aFEG0intxHxtl4+xY/IXfhxKGHA8CFmoRBKEM3EHMa1FGRViAVIGDjw= X-Google-Smtp-Source: APBJJlEdbh7/plYGexc2BDI2Nc3m7ARJwJ6WjtDE8/AFS5mSr8iYPnK6Wv4QIGmocWJc2kRA6v4tor0+PsfzFe6mLII= X-Received: by 2002:a25:f20d:0:b0:c6e:ee9e:7567 with SMTP id i13-20020a25f20d000000b00c6eee9e7567mr13312387ybe.29.1689177796608; Wed, 12 Jul 2023 09:03:16 -0700 (PDT) MIME-Version: 1.0 References: <9704a138-60e6-4ede-91f0-844e1df2ad84@moroto.mountain> <331201b2-5f13-8e81-b5d4-b17f8784d498@redhat.com> In-Reply-To: <331201b2-5f13-8e81-b5d4-b17f8784d498@redhat.com> From: Suren Baghdasaryan Date: Wed, 12 Jul 2023 09:03:02 -0700 Message-ID: Subject: Re: [bug report] mm: replace vma->vm_flags direct modifications with modifier calls To: David Hildenbrand Cc: Matthew Wilcox , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: jp4gnd19991ddpj3xb36qqpnk9q8kur8 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8527080050 X-HE-Tag: 1689177797-634965 X-HE-Meta: U2FsdGVkX19MCvpIhw3/stc/iv2n6yl+BCDAx2zC6hOH7/rpvEId5Qo+pyJRAbW4O5HAUWqL5seP6YLugQmg+sgVWgJ5f0f3XYR+i3w7al/MlrCVuFINXHqEDEaa5UBJAEQnQSg1FbV2f9y2N/5MXmPDZivJQnpWQ8bWo0JSaZQswqx9AUVGVt68KbY3IKW7Qv8MRBTDhKhUYRbPyW97HoQS8fQlScnA08GKSV4n03rtJXzmhkHkDZek4MxtdgI1gtM3jcPw9Q24AATiD68tT3d8ce9kZ1dWR4huXo1FmITENKf93b9V0HF/QYQSLkEP20wfukOvSRgroMDCncnHsA8PAXmVrl5vS8LnUVVfTVDURSonpqGDbEXyki4/7EATY/4yEOMD7shCqM57n4o2BzPKYvVqsE8sRpdlATJEjOIp4VSM3ASGTxZnZGyFfdIbgfmyc1vRur9kcncifBqTQBppJlaO0aDn9gIQoeiUSifBtRMFYeA6RQux9NSretTnh5397zqPpl3JNEp8yvxltsNdaMfSrPjL136q/Vh/GxlmNNXNrtn14nzjhH/IWW89sohSu9AuAgddWzEdYdX5Gv1Ih7sYzBhtrv1TR0kiJUboahyJWa9EYpNFOM4GCjxet1xTBkZ1qbL57yEiPIjFkksanDYXmSkdpDIl2vLJZ2XfXF9Iu69nmpDZPnkovSpu+/OcdbR5tGhz3VPLy7Qo70BbPaIULoGDY2pduu5p2CX5WRn7J68Hx+wx7BJ/dcxejH6vhiQCTXOLzUR/idGofIbSa5Ca43oOk0BvU8RhnUQXGvIUADnQqCSA62yQMLy9SvPRo55S/owvBVje5bvMMcs4W8ITwUfPxFVvTzGTslVRA+u8uVxjr9/AWN3olR7DUfSF8XE9SsYWwX5YLcMZWAbcR/ODFVFVKnE+iY8WCwukgpimEe6sVa4QVduCLv44WXvrk5HFjngr7ZufOiW yBMCVPiu nooeYxb5xQtBTvCgHRCMAWBah8w6Tmz5AntRoYrLHXpG0YhXs00RBbiQYBw30HmcxpKhXvfw9k9ey5kJ4W36cTkI9iU4RhCg+N49scuNAnEhYuNWMJvHoFVdADGDWMSUFY+aISZfMhPpgaPQrM6/Ec8EMUfRe/Ao71Qf4kRU15XFMtgheRmG1uwDiSRdyNbprC6HL9BShcDX94bYNT3d2xcMlXmkP5rOqrznrAjuLyx4QEGCkjohbcJg5q0ybDvA1nEiXZvYOiYmQXu+rOCVZxB/8j7VK/t17dFfn8fcIDbzuLGE= 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 Wed, Jul 12, 2023 at 8:55=E2=80=AFAM David Hildenbrand wrote: > > On 12.07.23 17:52, Matthew Wilcox wrote: > > On Wed, Jul 12, 2023 at 08:01:18AM -0700, Suren Baghdasaryan wrote: > >> Are you suggesting to break remap_pfn_range() into two stages > >> (remap_pfn_range_prepare() then remap_pfn_range())? > >> If so, there are many places remap_pfn_range() is called and IIUC all > >> of them would need to use that 2-stage approach (lots of code churn). > >> In addition, this is an exported function, so many more drivers might > >> expect the current behavior. > > > > You do not understand correctly. > > > > When somebody calls mmap, there are two reasonable implementations. > > Here's one: > > > > .mmap =3D snd_dma_iram_mmap, > > > > static int snd_dma_iram_mmap(struct snd_dma_buffer *dmab, > > struct vm_area_struct *area) > > { > > area->vm_page_prot =3D pgprot_writecombine(area->vm_page_prot)= ; > > return remap_pfn_range(area, area->vm_start, > > dmab->addr >> PAGE_SHIFT, > > area->vm_end - area->vm_start, > > area->vm_page_prot); > > } > > > > This is _fine_. It is not called from the fault path, it is called in > > process context. Few locks are held (which ones aren't even > > documented!) > > > > The other way is to set vma->vm_ops. The fault handler in vm_ops > > should not be calling remap_pfn_range(). It should be calling > > set_ptes(). I almost have this driver fixed up, but I have another > > meeting to go to now. > > Just a note that we still have to make sure that the VMA flags will be > set properly -- I guess at mmap time is the right time as I suggested abo= ve. Ah, ok, now I understand what you meant. Ok, let's wait for Matthew to send the fix for the driver. Sounds like he has it almost ready. > > -- > Cheers, > > David / dhildenb >