From: NeilBrown <neilb@suse.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
Matthew Wilcox <matthew.r.wilcox@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 3/3] radix-tree: support locking of individual exception entries.
Date: Wed, 09 Mar 2016 13:13:08 +1100 [thread overview]
Message-ID: <87oaaojt57.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20160304123112.GA17393@quack.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]
On Fri, Mar 04 2016, Jan Kara wrote:
> On Fri 04-03-16 21:14:24, NeilBrown wrote:
>> On Fri, Mar 04 2016, NeilBrown wrote:
>>
>> >
>> > By not layering on top of wait_bit_key, you've precluded the use of the
>> > current page wait_queues for these locks - you need to allocate new wait
>> > queue heads.
>> >
>> > If in
>> >
>> >> +struct wait_exceptional_entry_queue {
>> >> + wait_queue_t wait;
>> >> + struct exceptional_entry_key key;
>> >> +};
>> >
>> > you had the exceptional_entry_key first (like wait_bit_queue does) you
>> > would be closer to being able to re-use the queues.
>>
>> Scratch that bit, I was confusing myself again. Sorry.
>> Each wait_queue_t has it's own function so one function will never be
>> called on other items in the queue - of course.
>
> Yes.
I was thinking about this some more, wondering why I thought what I did,
and realised there is a small issue that it is worth being aware of.
If different users of the same work queue use different "keys", a wake
function can get a key of a different type to the one it is expecting.
e.g. __wake_up_bit passes the address of a "struct wait_bit_key" to
__wake_up which is then passed as a "void* arg" to the
wait_queue_func_t.
With your code, a "struct exceptional_entry_key" could be passed to
wake_bit_function, or a "struct wait_bit_key" could be passed to
wake_exceptional_entry_func.
Both structures start with a pointer which will never appear in the
wrong type, and both function test that pointer first and access nothing
else if it doesn't match, so the code is safe. But it could be seen as
a bit fragile, and doing something to make it obvious that the different
key types need to align on that primary key field would not be a bad
thing. .... If we end up using this code.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
next prev parent reply other threads:[~2016-03-09 2:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-28 5:09 [PATCH 0/3] RFC improvements to radix-tree related to DAX NeilBrown
2016-02-28 5:09 ` [PATCH 1/3] DAX: move RADIX_DAX_ definitions to dax.c NeilBrown
2016-02-29 14:28 ` Wilcox, Matthew R
2016-02-29 17:46 ` Ross Zwisler
2016-02-28 5:09 ` [PATCH 3/3] radix-tree: support locking of individual exception entries NeilBrown
2016-02-28 5:30 ` kbuild test robot
2016-02-28 6:27 ` NeilBrown
2016-03-03 13:10 ` Jan Kara
2016-03-03 23:51 ` NeilBrown
2016-03-04 10:14 ` NeilBrown
2016-03-04 12:31 ` Jan Kara
2016-03-09 2:13 ` NeilBrown [this message]
2016-02-28 5:09 ` [PATCH 2/3] radix-tree: make 'indirect' bit available to " NeilBrown
2016-02-29 14:41 ` Wilcox, Matthew R
2016-03-01 21:59 ` Ross Zwisler
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=87oaaojt57.fsf@notabene.neil.brown.name \
--to=neilb@suse.com \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 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).