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 D7CF9C47DD9 for ; Fri, 22 Mar 2024 03:18:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6DE5E6B0083; Thu, 21 Mar 2024 23:18:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 640836B0087; Thu, 21 Mar 2024 23:18:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 493796B0088; Thu, 21 Mar 2024 23:18:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 32DBB6B0083 for ; Thu, 21 Mar 2024 23:18:21 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id EC15480A63 for ; Fri, 22 Mar 2024 03:18:20 +0000 (UTC) X-FDA: 81923216760.21.9B63921 Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by imf27.hostedemail.com (Postfix) with ESMTP id F167F4000E for ; Fri, 22 Mar 2024 03:18:18 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=XPVboFOM; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf27.hostedemail.com: domain of david@fromorbit.com designates 209.85.210.176 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711077499; 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=n84vaghGfbDLCoFpfil71Abo8071Ln4FsAGbxQu2tPw=; b=8K4AlGu7RI1OutmNve95inihVNcUSds4dwZaEQbR7S4TzC6Wf8pXW/6npiQpr4FTRdmEv3 Olp/WenpvYOSs/+TF3W0M6C77BLZb+RJVNKMDYdNtSVACldOj7UAxFCcw0F3VqdGnAnuw7 Mk9EB//CeCz4W1J4CUlTDvbrFNoWH6k= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=XPVboFOM; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf27.hostedemail.com: domain of david@fromorbit.com designates 209.85.210.176 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711077499; a=rsa-sha256; cv=none; b=okB5q1Qh3MmwmvUwK44I7P/uY/ot8yvimSr8D7c6coXjojBuChcSL4Sw/HRvk6e1LsxLIA 5RrAQ3WLm8ONZVkvluz1NWlzeAe5W/tjzT2PxOCcjtmvmeKcjN7kkLNBhnpphgA3GMWJtp MHUpLFi5wiKDRmgdZ4rN8tTfwSk4xT8= Received: by mail-pf1-f176.google.com with SMTP id d2e1a72fcca58-6ea7f2d093aso501283b3a.3 for ; Thu, 21 Mar 2024 20:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1711077498; x=1711682298; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=n84vaghGfbDLCoFpfil71Abo8071Ln4FsAGbxQu2tPw=; b=XPVboFOMAD2h32hDvz5tXIo9+stw/sgfUSytdrjMvj8yOYrGZ7/Gb3+RQalkDwjr7S f+IrHOXCarwbPemXib1sJx4BzwBaVxs6uaiH+BR4UI4hE7/335y7WJ9jHutZEJq2B1Vb hytSu1U+vj8e+nMQahmQTzmqLwk0czkwsLRHuNcJBQUCEQEZLoqqIwgqTPSZvTL/XHut EFPa40fuUXrN5qmifLjQw7TXwkXh0zDhhEQ6GiVVm3k3+xNaGWC5fejvVXX6wFPx51ph h50MOHwIQZU1z0c4ZyNW4wARuBglES9snxs0KNW0vdEEKN9s0G2wgQFndpz1nEQp1v0d gAHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711077498; x=1711682298; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=n84vaghGfbDLCoFpfil71Abo8071Ln4FsAGbxQu2tPw=; b=vnmydyYS+SJu2cHxKPImfsvN31TM9HibhTeWh1MrBy45R5ob1B8uT7b384/f0Gzblj gv4WURG58PoGXmLIkHlUaj7tPMyeQCFS+mMt4EkdGaNlh8tVUAC40XfVx8INGaYkAWQi z0yX74CgMI6YRNQC5EnwTDC1h7Y6g+Of6nH6A03hXOwAH5Ve77FBSZmHiBsAhVZE8yH/ MWzchZHzpXnqHajbcVgeqE/ytRICbgL8NTeCS/fKgTmwlnhTYjXC4lNQzY36vN4zDtfw HCfkO6XK8XbvyAx/yA5DIxzT2esx3VxQMhgX1Ux+gvL1e+P3vz4wPxmTi6lhMBn1aufO 4BzQ== X-Forwarded-Encrypted: i=1; AJvYcCWjELrhyIdDfxPhU0j9l2Kz4dpuzc3abz4eP/OEgfFb44yJscAU6b+JW8rJHGUkyZXM6h9llPc8W83FMLD+1jibU/U= X-Gm-Message-State: AOJu0YyIxIAGHavjokcOLqqn1pnBkPnJD+zdsKZVYh4cwLJtcsR6b2h9 GtnX/xC5qBKv8Labb1MPMlseXYPnZmYpononhHTdrGdVvDaEXVaEv+dJeL5c2wk= X-Google-Smtp-Source: AGHT+IGlBISBZOl2AHGgNnki6HcX5k6G0GbLlF5Tla+rxx/OW7wqGuenHv++R8pDFbVQBt9lkwKjqQ== X-Received: by 2002:a05:6a00:2d95:b0:6ea:7486:84ac with SMTP id fb21-20020a056a002d9500b006ea748684acmr1596494pfb.4.1711077497534; Thu, 21 Mar 2024 20:18:17 -0700 (PDT) Received: from dread.disaster.area (pa49-181-56-237.pa.nsw.optusnet.com.au. [49.181.56.237]) by smtp.gmail.com with ESMTPSA id r11-20020aa79ecb000000b006ea6d1d3134sm585074pfq.119.2024.03.21.20.18.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Mar 2024 20:18:16 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1rnVQ5-005aqD-2Y; Fri, 22 Mar 2024 14:18:13 +1100 Date: Fri, 22 Mar 2024 14:18:13 +1100 From: Dave Chinner To: Alistair Popple Cc: Dan Williams , linux-mm@kvack.org, jhubbard@nvidia.com, rcampbell@nvidia.com, willy@infradead.org, jgg@nvidia.com, linux-fsdevel@vger.kernel.org, jack@suse.cz, djwong@kernel.org, hch@lst.de, david@redhat.com, ruansy.fnst@fujitsu.com Subject: Re: ZONE_DEVICE refcounting Message-ID: References: <87ttlhmj9p.fsf@nvdebian.thelocal> <65f148866bc56_a9b42947@dwillia2-mobl3.amr.corp.intel.com.notmuch> <87y1ad776c.fsf@nvdebian.thelocal> <878r2c6t99.fsf@nvdebian.thelocal> <65fbcdaf2042f_aa222948c@dwillia2-mobl3.amr.corp.intel.com.notmuch> <874jcz6ryu.fsf@nvdebian.thelocal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874jcz6ryu.fsf@nvdebian.thelocal> X-Rspamd-Queue-Id: F167F4000E X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: oe5itxj5ssowthxctct6qboaw8wjssu3 X-HE-Tag: 1711077498-859486 X-HE-Meta: U2FsdGVkX1/4vHqv4JGrEdxOZrbpWATf8sNpkDN1b9PWLfMTplqMISOyjGq9TqTGix4Ft9qOEog3KtSXYtf7QmfB9fdu8lkhXvOhQKeGNkg+Fy8YhY9S7INAeKiZd4EAdzJh1+oQT+9/9kCaMqB/MM3vbNOknh1U5nTuD2okUQ/6PaNwaDImqHL2xe1jK7KwJp1yFxVSrhQAfkOONT2Ok/fefcBNYNpxWMPS550iNfy7RM3aV5GMhhb9purGMC/gGORqPgm3Uwdx4ZVDOlfS7p13AZcAVBmOuN7WtDovAcZcD6iIviDyCGO048u2D92dhiyH2O/s6hC6LqlGAESnGUMskFN//dz7FkB4OYLnsG5wemSF9MkerG7PEbrmtd7Sreb/sa1li3+ASjI+ZiuFlI7sj7pyH6yRL04rgl6hpP81b0YfPyFj5Q272V9Y3mYd1YsBjj7FArHxYtUS48Mp4RlhDhnG1z3dSFnbIltTDp+flWY2G+gcESFkG5M6Fn6qqAoLm7M8qStjHKTqAo3G6UK5aoe0eItA/HlAy/dHqtrUaf2K4gaMfE+kYdqifdSeP17cJXVkSuLQ0Zxj1M/pM5VeoEnohTxMDLMAo5exUT1ayAUkNiGzrkULqGs8O/CegkcD+J1kEOtZYVT9qvuP4XF1UkDNs0DplgYgHy9lVjNbAiRkeWgnpNoqGSxwTxtsYx08cs8c+ASN+nu9xVFAD5dJdlzQKrlwYbLirSWglf1na4ZMg45KWsxjDbyu/hwI4UeACnDwbASIBlLTUIrBhZ/dK9dAJdzOOH/Jl3y2LGJzrcQu3ESTn1n7jkN+FlkH3nDjiC+Xjmi5EbYlQumjAY3iIClc/qyk3mqYwgrGndClPOGxklpRhYfeHOHcLooPsBUOgPqEeHj8b6pZdk52bHCRWytKWd5XL74jMiOfDuh1IyT87t35hmpl9wOtwoDlMZIU2UCd1QiW/j5JIAi Y5gD+g5o affPsjkPkaPSv3kuIsqWYlTnbs5UNBmaRN6c+0fz4QLNpru+6TGyfAxkTCbJ74ngjpNA8b+iyyp4LoJWpbh3ZRhBlHPFycDEuEyd+e/g1RqUWvc7ww00D/HXthWaDDF+4TGtqTcfP1aS+ZX5ySe7aIGuHcG0ZVYrQbte6jjo4at7/f7m0uET9XW6/EsbRXdvLkyQ4EjHZ59TliUfZU6BHdL2R9vw2VvqIoosU/G8bJJWwkzfXmpbcPjNtBmblLSbpLn9wGn0RiwpDPGwPdbghZQalToAaVIYGUS6EUkVEI0LzhCLb6sMEZbxdbkbomXQZYuZuSrdI0p2EIQZoqMccSwrlwulOZ5kXn1hSIAtV0NMoP7NfXs0YjNDiuQOJIZBF6u5RjrKYsHZbzlcthjNr/Kd68Xh7hP1Q4aw0U0KKKMwkSYb4Oaqun2QKIGyxnnlB07LFSrJsY2prTA6nPC4+ouBlbhYYV0Ruq3jYdaaXxCy3K09G9z3Eu6JCWNBTZwypM7xJ1i/GwJYvIHRRCuwqSsk5o5ua0fdwMXEVrLf5QTM1omdy4oRioaJuOevteAKIkwYl 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: List-Subscribe: List-Unsubscribe: On Fri, Mar 22, 2024 at 11:01:25AM +1100, Alistair Popple wrote: > > Dan Williams writes: > > > Alistair Popple wrote: > >> > >> Alistair Popple writes: > >> > >> > Dan Williams writes: > >> > > >> >> Alistair Popple wrote: > >> > > >> > I also noticed folio_anon() is not safe to call on a FS DAX page due to > >> > sharing PAGE_MAPPING_DAX_SHARED. > >> > >> Also it feels like I could be missing something here. AFAICT the > >> page->mapping and page->index fields can't actually be used outside of > >> fs/dax because they are overloaded for the shared case. Therefore > >> setting/clearing them could be skipped and the only reason for doing so > >> is so dax_associate_entry()/dax_disassociate_entry() can generate > >> warnings which should never occur anyway. So all that code is > >> functionally unnecessary. > > > > What do you mean outside of fs/dax, do you literally mean outside of > > fs/dax.c, or the devdax case (i.e. dax without fs-entanglements)? > > Only the cases fs dax pages might need it. ie. Not devdax which I > haven't looked at closely yet. > > > Memory > > failure needs ->mapping and ->index to rmap dax pages. See > > mm/memory-failure.c::__add_to_kill() and > > mm/memory-failure.c::__add_to_kill_fsdax() where that latter one is for > > cases where the fs needs has signed up to react to dax page failure. > > How does that work for reflink/shared pages which overwrite > page->mapping and page->index? Via reverse mapping in the *filesystem*, not the mm rmap stuff. pmem_pagemap_memory_failure() dax_holder_notify_failure() .notify_failure() xfs_dax_notify_failure() xfs_dax_notify_ddev_failure() xfs_rmap_query_range(xfs_dax_failure_fn) xfs_dax_failure_fn(rmap record) mf_dax_kill_procs(inode->mapping, pgoff) collect_procs_fsdax(mapping, page) add_to_kill_fsdax(task) __add_to_kill(task) unmap_and_kill_tasks() Remember: in FSDAX, the pages are the storage media physically owned by the filesystem, not the mm subsystem. Hence answering questions like "who owns this page" can only be answered correctly by asking the filesystem. We shortcut that for pages that only have one owner - we just store the owner information in the page as a {mapping, offset} tuple. But when we have multiple owners, the only way to find all the {mapping, offset} tuples is to ask the filesystem to find all the owners of that page. Hence the special case values for page->mapping/page->index for pages over shared filesystem extents. These shared extents are communicated to the fsdax layer via the IOMAP_F_SHARED flag in the iomaps returned by the filesystem. This flag is the trigger for the special mapping share count behaviour to be used. e.g. see dax_insert_entry(iomap_iter) -> dax_associate_entry(shared) -> dax_page_share_get().... > Eg. in __add_to_kill() if *p is a shared fs > dax page then p->mapping == PAGE_MAPPING_DAX_SHARED and > page_address_in_vma(vma, p) will probably crash. As per above, we don't get the mapping from the page in those cases. If you haven't got access to the page though a filesystem method and guaranteed that truncate() can't free it from under you, then you're probably doing the wrong thing with fsdax... -Dave. -- Dave Chinner david@fromorbit.com