From: Kent Overstreet <kent.overstreet@gmail.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Dave Chinner <dchinner@redhat.com>,
Waiman Long <longman@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-bcache@vger.kernel.org,
"Darrick J . Wong" <darrick.wong@oracle.com>,
Zach Brown <zach.brown@ni.com>, Jens Axboe <axboe@kernel.dk>,
Josef Bacik <josef@toxicpanda.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>
Subject: Re: bcachefs status update (it's done cooking; let's get this sucker merged)
Date: Wed, 12 Jun 2019 12:21:44 -0400 [thread overview]
Message-ID: <20190612162144.GA7619@kmo-pixel> (raw)
In-Reply-To: <20190611043336.GB14363@dread.disaster.area>
On Tue, Jun 11, 2019 at 02:33:36PM +1000, Dave Chinner wrote:
> I just recently said this with reference to the range lock stuff I'm
> working on in the background:
>
> FWIW, it's to avoid problems with stupid userspace stuff
> that nobody really should be doing that I want range locks
> for the XFS inode locks. If userspace overlaps the ranges
> and deadlocks in that case, they they get to keep all the
> broken bits because, IMO, they are doing something
> monumentally stupid. I'd probably be making it return
> EDEADLOCK back out to userspace in the case rather than
> deadlocking but, fundamentally, I think it's broken
> behaviour that we should be rejecting with an error rather
> than adding complexity trying to handle it.
>
> So I think this recusive locking across a page fault case should
> just fail, not add yet more complexity to try to handle a rare
> corner case that exists more in theory than in reality. i.e put the
> lock context in the current task, then if the page fault requires a
> conflicting lock context to be taken, we terminate the page fault,
> back out of the IO and return EDEADLOCK out to userspace. This works
> for all types of lock contexts - only the filesystem itself needs to
> know what the lock context pointer contains....
Ok, I'm totally on board with returning EDEADLOCK.
Question: Would we be ok with returning EDEADLOCK for any IO where the buffer is
in the same address space as the file being read/written to, even if the buffer
and the IO don't technically overlap?
This would simplify things a lot and eliminate a really nasty corner case - page
faults trigger readahead. Even if the buffer and the direct IO don't overlap,
readahead can pull in pages that do overlap with the dio.
And on getting EDEADLOCK we could fall back to buffered IO, so userspace would
never know...
next prev parent reply other threads:[~2019-06-12 16:21 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-10 19:14 bcachefs status update (it's done cooking; let's get this sucker merged) Kent Overstreet
2019-06-10 19:14 ` [PATCH 01/12] Compiler Attributes: add __flatten Kent Overstreet
2019-06-12 17:16 ` Greg KH
2019-06-10 19:14 ` [PATCH 02/12] locking: SIX locks (shared/intent/exclusive) Kent Overstreet
2019-06-10 19:14 ` [PATCH 03/12] mm: pagecache add lock Kent Overstreet
2019-06-10 19:14 ` [PATCH 04/12] mm: export find_get_pages() Kent Overstreet
2019-06-10 19:14 ` [PATCH 05/12] fs: insert_inode_locked2() Kent Overstreet
2019-06-10 19:14 ` [PATCH 06/12] fs: factor out d_mark_tmpfile() Kent Overstreet
2019-06-10 19:14 ` [PATCH 07/12] Propagate gfp_t when allocating pte entries from __vmalloc Kent Overstreet
2019-06-10 19:14 ` [PATCH 08/12] block: Add some exports for bcachefs Kent Overstreet
2019-06-10 19:14 ` [PATCH 09/12] bcache: optimize continue_at_nobarrier() Kent Overstreet
2019-06-10 19:14 ` [PATCH 10/12] bcache: move closures to lib/ Kent Overstreet
2019-06-11 10:25 ` Coly Li
2019-06-13 7:28 ` Christoph Hellwig
2019-06-13 11:04 ` Kent Overstreet
2019-06-10 19:14 ` [PATCH 11/12] closures: closure_wait_event() Kent Overstreet
2019-06-11 10:25 ` Coly Li
2019-06-12 17:17 ` Greg KH
2019-06-10 19:14 ` [PATCH 12/12] closures: fix a race on wakeup from closure_sync Kent Overstreet
2019-07-16 10:47 ` Coly Li
2019-07-18 7:46 ` Coly Li
2019-07-22 17:22 ` Kent Overstreet
2020-11-24 23:07 ` Marc Smith
2020-11-25 18:10 ` Marc Smith
2019-06-10 20:46 ` bcachefs status update (it's done cooking; let's get this sucker merged) Linus Torvalds
2019-06-11 1:17 ` Kent Overstreet
2019-06-11 4:33 ` Dave Chinner
2019-06-12 16:21 ` Kent Overstreet [this message]
2019-06-12 23:02 ` Dave Chinner
2019-06-13 18:36 ` pagecache locking (was: bcachefs status update) merged) Kent Overstreet
2019-06-13 21:13 ` Andreas Dilger
2019-06-13 21:21 ` Kent Overstreet
2019-06-14 0:35 ` Dave Chinner
2019-06-13 23:55 ` Dave Chinner
2019-06-14 2:30 ` Linus Torvalds
2019-06-14 7:30 ` Dave Chinner
2019-06-15 1:15 ` Linus Torvalds
2019-06-14 3:08 ` Linus Torvalds
2019-06-15 4:01 ` Linus Torvalds
2019-06-17 22:47 ` Dave Chinner
2019-06-17 23:38 ` Linus Torvalds
2019-06-18 4:21 ` Amir Goldstein
2019-06-19 10:38 ` Jan Kara
2019-06-19 22:37 ` Dave Chinner
2019-07-03 0:04 ` pagecache locking Boaz Harrosh
[not found] ` <DM6PR19MB250857CB8A3A1C8279D6F2F3C5FB0@DM6PR19MB2508.namprd19.prod.outlook.com>
2019-07-03 1:25 ` Boaz Harrosh
2019-07-05 23:31 ` Dave Chinner
2019-07-07 15:05 ` Boaz Harrosh
2019-07-07 23:55 ` Dave Chinner
2019-07-08 13:31 ` Jan Kara
2019-07-09 23:47 ` Dave Chinner
2019-07-10 8:41 ` Jan Kara
2019-06-14 17:08 ` pagecache locking (was: bcachefs status update) merged) Kent Overstreet
2019-06-19 8:21 ` bcachefs status update (it's done cooking; let's get this sucker merged) Jan Kara
2019-07-03 1:04 ` [PATCH] mm: Support madvise_willneed override by Filesystems Boaz Harrosh
2019-07-03 17:21 ` Jan Kara
2019-07-03 18:03 ` Boaz Harrosh
2019-06-11 4:55 ` bcachefs status update (it's done cooking; let's get this sucker merged) Linus Torvalds
2019-06-11 14:26 ` Matthew Wilcox
2019-06-11 4:10 ` Dave Chinner
2019-06-11 4:39 ` Linus Torvalds
2019-06-11 7:10 ` Dave Chinner
2019-06-12 2:07 ` Linus Torvalds
2019-07-03 5:59 ` Stefan K
2020-06-10 11:02 ` Stefan K
2020-06-10 11:32 ` Kent Overstreet
2019-06-29 16:39 Luke Kenneth Casson Leighton
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=20190612162144.GA7619@kmo-pixel \
--to=kent.overstreet@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=dchinner@redhat.com \
--cc=josef@toxicpanda.com \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=peterz@infradead.org \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=zach.brown@ni.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.