From: Jan Kara <jack@suse.cz> To: Matthew Wilcox <willy@infradead.org> Cc: Seema Pandit <seema.pandit@intel.com>, linux-nvdimm <linux-nvdimm@lists.01.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, stable <stable@vger.kernel.org>, Robert Barror <robert.barror@intel.com>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, Jan Kara <jack@suse.cz> Subject: Re: [PATCH] filesystem-dax: Disable PMD support Date: Thu, 4 Jul 2019 18:40:36 +0200 [thread overview] Message-ID: <20190704164036.GG31037@quack2.suse.cz> (raw) In-Reply-To: <20190703154700.GI1729@bombadil.infradead.org> On Wed 03-07-19 08:47:00, Matthew Wilcox wrote: > On Mon, Jul 01, 2019 at 02:11:19PM +0200, Jan Kara wrote: > > BTW, looking into the xarray code, I think I found another difference > > between the old radix tree code and the new xarray code that could cause > > issues. In the old radix tree code if we tried to insert PMD entry but > > there was some PTE entry in the covered range, we'd get EEXIST error back > > and the DAX fault code relies on this. I don't see how similar behavior is > > achieved by xas_store()... > > Are you referring to this? > > - entry = dax_make_locked(0, size_flag | DAX_EMPTY); > - > - err = __radix_tree_insert(&mapping->i_pages, index, > - dax_entry_order(entry), entry); > - radix_tree_preload_end(); > - if (err) { > - xa_unlock_irq(&mapping->i_pages); > - /* > - * Our insertion of a DAX entry failed, most likely > - * because we were inserting a PMD entry and it > - * collided with a PTE sized entry at a different > - * index in the PMD range. We haven't inserted > - * anything into the radix tree and have no waiters to > - * wake. > - */ > - return ERR_PTR(err); > - } Mostly yes. > If so, that can't happen any more because we no longer drop the i_pages > lock while the entry is NULL, so the entry is always locked while the > i_pages lock is dropped. Ah, I have misinterpretted what xas_find_conflict() does. I'm sorry for the noise. I find it somewhat unfortunate that xas_find_conflict() will not return in any way the index where it has found the conflicting entry. We could then use it for the wait logic as well and won't have to resort to some masking tricks... Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz> To: Matthew Wilcox <willy@infradead.org> Cc: Jan Kara <jack@suse.cz>, Dan Williams <dan.j.williams@intel.com>, Seema Pandit <seema.pandit@intel.com>, linux-nvdimm <linux-nvdimm@lists.01.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, stable <stable@vger.kernel.org>, Robert Barror <robert.barror@intel.com>, linux-fsdevel <linux-fsdevel@vger.kernel.org> Subject: Re: [PATCH] filesystem-dax: Disable PMD support Date: Thu, 4 Jul 2019 18:40:36 +0200 [thread overview] Message-ID: <20190704164036.GG31037@quack2.suse.cz> (raw) In-Reply-To: <20190703154700.GI1729@bombadil.infradead.org> On Wed 03-07-19 08:47:00, Matthew Wilcox wrote: > On Mon, Jul 01, 2019 at 02:11:19PM +0200, Jan Kara wrote: > > BTW, looking into the xarray code, I think I found another difference > > between the old radix tree code and the new xarray code that could cause > > issues. In the old radix tree code if we tried to insert PMD entry but > > there was some PTE entry in the covered range, we'd get EEXIST error back > > and the DAX fault code relies on this. I don't see how similar behavior is > > achieved by xas_store()... > > Are you referring to this? > > - entry = dax_make_locked(0, size_flag | DAX_EMPTY); > - > - err = __radix_tree_insert(&mapping->i_pages, index, > - dax_entry_order(entry), entry); > - radix_tree_preload_end(); > - if (err) { > - xa_unlock_irq(&mapping->i_pages); > - /* > - * Our insertion of a DAX entry failed, most likely > - * because we were inserting a PMD entry and it > - * collided with a PTE sized entry at a different > - * index in the PMD range. We haven't inserted > - * anything into the radix tree and have no waiters to > - * wake. > - */ > - return ERR_PTR(err); > - } Mostly yes. > If so, that can't happen any more because we no longer drop the i_pages > lock while the entry is NULL, so the entry is always locked while the > i_pages lock is dropped. Ah, I have misinterpretted what xas_find_conflict() does. I'm sorry for the noise. I find it somewhat unfortunate that xas_find_conflict() will not return in any way the index where it has found the conflicting entry. We could then use it for the wait logic as well and won't have to resort to some masking tricks... Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR
next prev parent reply other threads:[~2019-07-04 16:40 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-27 0:15 [PATCH] filesystem-dax: Disable PMD support Dan Williams 2019-06-27 0:15 ` Dan Williams 2019-06-27 12:34 ` Matthew Wilcox 2019-06-27 12:34 ` Matthew Wilcox 2019-06-27 16:06 ` Dan Williams 2019-06-27 16:06 ` Dan Williams 2019-06-27 18:29 ` Dan Williams 2019-06-27 18:29 ` Dan Williams 2019-06-27 18:58 ` Dan Williams 2019-06-27 18:58 ` Dan Williams 2019-06-27 19:09 ` Dan Williams 2019-06-27 19:09 ` Dan Williams 2019-06-27 19:59 ` Matthew Wilcox 2019-06-27 19:59 ` Matthew Wilcox 2019-06-28 2:39 ` Dan Williams 2019-06-28 2:39 ` Dan Williams 2019-06-28 16:37 ` Matthew Wilcox 2019-06-28 16:37 ` Matthew Wilcox 2019-06-28 16:39 ` Dan Williams 2019-06-28 16:39 ` Dan Williams 2019-06-28 16:54 ` Matthew Wilcox 2019-06-28 16:54 ` Matthew Wilcox 2019-06-29 16:03 ` Matthew Wilcox 2019-06-29 16:03 ` Matthew Wilcox 2019-06-30 7:27 ` Dan Williams 2019-06-30 7:27 ` Dan Williams 2019-06-30 8:01 ` Dan Williams 2019-06-30 8:01 ` Dan Williams 2019-06-30 15:23 ` Matthew Wilcox 2019-06-30 15:23 ` Matthew Wilcox 2019-06-30 21:37 ` Dan Williams 2019-06-30 21:37 ` Dan Williams 2019-07-02 3:34 ` Matthew Wilcox 2019-07-02 3:34 ` Matthew Wilcox 2019-07-02 15:37 ` Dan Williams 2019-07-02 15:37 ` Dan Williams 2019-07-03 0:22 ` Boaz Harrosh 2019-07-03 0:22 ` Boaz Harrosh 2019-07-03 0:42 ` Dan Williams 2019-07-03 0:42 ` Dan Williams 2019-07-03 1:39 ` Boaz Harrosh 2019-07-03 1:39 ` Boaz Harrosh 2019-07-01 12:11 ` Jan Kara 2019-07-01 12:11 ` Jan Kara 2019-07-03 15:47 ` Matthew Wilcox 2019-07-03 15:47 ` Matthew Wilcox 2019-07-04 16:40 ` Jan Kara [this message] 2019-07-04 16:40 ` Jan Kara
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=20190704164036.GG31037@quack2.suse.cz \ --to=jack@suse.cz \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nvdimm@lists.01.org \ --cc=robert.barror@intel.com \ --cc=seema.pandit@intel.com \ --cc=stable@vger.kernel.org \ --cc=willy@infradead.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.