All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org, "Wilcox,
	Matthew R" <matthew.r.wilcox@intel.com>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	linux-nvdimm@lists.01.org
Subject: Re: [PATCH 12/12] dax: New fault locking
Date: Wed, 23 Mar 2016 08:10:42 +1100	[thread overview]
Message-ID: <87h9fycj71.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20160318153919.GG7152@quack.suse.cz>

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

On Sat, Mar 19 2016, Jan Kara wrote:
>
> Actually, after some thought I don't think the wakeup is needed except for
> dax_pfn_mkwrite(). In the other cases we know there is no radix tree
> exceptional entry and thus there can be no waiters for its lock...
>

I think that is fragile logic - though it may be correct at present.

A radix tree slot can transition from "Locked exception" to "unlocked
exception" to "deleted" to "struct page".

So it is absolutely certain that a thread cannot go to sleep after
finding a "locked exception" and wake up to find a "struct page" ??

How about a much simpler change.
 - new local variable "slept" in lookup_unlocked_mapping_entry() which
   is set if prepare_to_wait_exclusive() gets called.
 - if after __radix_tree_lookup() returns:
        (ret==NULL || !radix_tree_exceptional_entry(ret)) && slept
   then it calls wakeup immediately - because if it was waiting,
   something else might be to.

That would cover all vaguely possible cases except dax_pfn_mkwrite()


Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: NeilBrown <neilb@suse.com>
To: Jan Kara <jack@suse.cz>
Cc: Jan Kara <jack@suse.cz>, linux-fsdevel@vger.kernel.org, "Wilcox\,
	Matthew R" <matthew.r.wilcox@intel.com>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	linux-nvdimm@lists.01.org
Subject: Re: [PATCH 12/12] dax: New fault locking
Date: Wed, 23 Mar 2016 08:10:42 +1100	[thread overview]
Message-ID: <87h9fycj71.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20160318153919.GG7152@quack.suse.cz>

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

On Sat, Mar 19 2016, Jan Kara wrote:
>
> Actually, after some thought I don't think the wakeup is needed except for
> dax_pfn_mkwrite(). In the other cases we know there is no radix tree
> exceptional entry and thus there can be no waiters for its lock...
>

I think that is fragile logic - though it may be correct at present.

A radix tree slot can transition from "Locked exception" to "unlocked
exception" to "deleted" to "struct page".

So it is absolutely certain that a thread cannot go to sleep after
finding a "locked exception" and wake up to find a "struct page" ??

How about a much simpler change.
 - new local variable "slept" in lookup_unlocked_mapping_entry() which
   is set if prepare_to_wait_exclusive() gets called.
 - if after __radix_tree_lookup() returns:
        (ret==NULL || !radix_tree_exceptional_entry(ret)) && slept
   then it calls wakeup immediately - because if it was waiting,
   something else might be to.

That would cover all vaguely possible cases except dax_pfn_mkwrite()


Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

  reply	other threads:[~2016-03-22 21:10 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-10 19:18 [RFC] [PATCH 0/12] DAX page fault locking Jan Kara
2016-03-10 19:18 ` Jan Kara
2016-03-10 19:18 ` [PATCH 01/12] DAX: move RADIX_DAX_ definitions to dax.c Jan Kara
2016-03-10 19:18   ` Jan Kara
2016-03-11 22:54   ` Ross Zwisler
2016-03-11 22:54     ` Ross Zwisler
2016-03-10 19:18 ` [PATCH 02/12] radix-tree: make 'indirect' bit available to exception entries Jan Kara
2016-03-10 19:18   ` Jan Kara
2016-03-10 19:18 ` [PATCH 03/12] mm: Remove VM_FAULT_MINOR Jan Kara
2016-03-10 19:18   ` Jan Kara
2016-03-10 19:38   ` Wilcox, Matthew R
2016-03-10 19:38     ` Wilcox, Matthew R
2016-03-10 19:48     ` Jan Kara
2016-03-10 19:48       ` Jan Kara
2016-03-10 19:18 ` [PATCH 04/12] ocfs2: Fix return value from ocfs2_page_mkwrite() Jan Kara
2016-03-10 19:18   ` Jan Kara
2016-03-10 19:18 ` [PATCH 05/12] dax: Remove synchronization using i_mmap_lock Jan Kara
2016-03-10 19:55   ` Wilcox, Matthew R
2016-03-10 19:55     ` Wilcox, Matthew R
2016-03-10 20:05     ` Jan Kara
2016-03-10 20:05       ` Jan Kara
2016-03-10 20:10       ` Wilcox, Matthew R
2016-03-10 20:10         ` Wilcox, Matthew R
2016-03-14 10:01         ` Jan Kara
2016-03-14 10:01           ` Jan Kara
2016-03-14 14:51           ` Wilcox, Matthew R
2016-03-14 14:51             ` Wilcox, Matthew R
2016-03-15  9:50             ` Jan Kara
2016-03-15  9:50               ` Jan Kara
2016-03-10 19:18 ` [PATCH 06/12] dax: Remove complete_unwritten argument Jan Kara
2016-03-10 19:18   ` Jan Kara
2016-03-10 19:18 ` [PATCH 07/12] dax: Fix data corruption for written and mmapped files Jan Kara
2016-03-10 19:18   ` Jan Kara
2016-03-10 19:18 ` [PATCH 08/12] dax: Fix bogus fault return value on cow faults Jan Kara
2016-03-10 19:18   ` Jan Kara
2016-03-10 19:18 ` [PATCH 09/12] dax: Allow DAX code to replace exceptional entries Jan Kara
2016-03-10 19:18   ` Jan Kara
2016-03-10 19:18 ` [PATCH 10/12] dax: Remove redundant inode size checks Jan Kara
2016-03-10 19:18   ` Jan Kara
2016-03-10 19:18 ` [PATCH 11/12] dax: Disable huge page handling Jan Kara
2016-03-10 19:34   ` Dan Williams
2016-03-10 19:34     ` Dan Williams
2016-03-10 19:52     ` Jan Kara
2016-03-10 19:52       ` Jan Kara
2016-03-10 19:18 ` [PATCH 12/12] dax: New fault locking Jan Kara
2016-03-10 19:18   ` Jan Kara
2016-03-10 23:54   ` NeilBrown
2016-03-10 23:54     ` NeilBrown
2016-03-15 21:34     ` NeilBrown
2016-03-15 21:34       ` NeilBrown
2016-03-18 14:16       ` Jan Kara
2016-03-18 14:16         ` Jan Kara
2016-03-18 15:39         ` Jan Kara
2016-03-18 15:39           ` Jan Kara
2016-03-22 21:10           ` NeilBrown [this message]
2016-03-22 21:10             ` NeilBrown
2016-03-23 11:00             ` Jan Kara
2016-03-23 11:00               ` Jan Kara
2016-03-31  4:20               ` NeilBrown
2016-03-31  4:20                 ` NeilBrown
2016-03-31  8:54                 ` Jan Kara
2016-03-31  8:54                   ` Jan Kara
2016-04-01  0:34                   ` NeilBrown
2016-04-01  0:34                     ` NeilBrown

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=87h9fycj71.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=dan.j.williams@intel.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=matthew.r.wilcox@intel.com \
    --cc=ross.zwisler@linux.intel.com \
    /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
Be 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.