On Tue, Sep 01, 2015 at 09:06:08AM +0200, Christoph Hellwig wrote:
> On Tue, Sep 01, 2015 at 09:38:03AM +1000, Dave Chinner wrote:
> > On Mon, Aug 31, 2015 at 12:59:44PM -0600, Ross Zwisler wrote:
> > > For DAX msync we just need to flush the given range using
> > > wb_c
On Tue, Sep 01, 2015 at 01:08:04PM +0300, Kirill A. Shutemov wrote:
> On Tue, Sep 01, 2015 at 09:38:03AM +1000, Dave Chinner wrote:
> > On Mon, Aug 31, 2015 at 12:59:44PM -0600, Ross Zwisler wrote:
> > Even for DAX, msync has to call vfs_fsync_range() for the filesystem to
>
lab
> merging for all of DM's slabs by using SLAB_NO_MERGE.
Seems like a fine idea to me. I can apply it to various slabs in XFS
once it's merged
Acked-by: Dave Chinner
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line
This undoes most of the changes introduced by those two commits,
> essentially returning us to the DAX locking scheme that was used in v4.2.
>
> Signed-off-by: Ross Zwisler
I've run this through some testing, the deadlocks aren't present and
there don't appear to be any new re
On Mon, Oct 12, 2015 at 11:21:56AM -0600, Ross Zwisler wrote:
> On Mon, Oct 12, 2015 at 10:14:43AM +1100, Dave Chinner wrote:
> > On Fri, Oct 09, 2015 at 04:02:08PM -0600, Ross Zwisler wrote:
> <>
> > > +/*
> > > + * The lock ordering for ext2 DAX fault paths
On Mon, Oct 12, 2015 at 03:41:35PM -0600, Ross Zwisler wrote:
> On Mon, Oct 12, 2015 at 10:14:43AM +1100, Dave Chinner wrote:
> > On Fri, Oct 09, 2015 at 04:02:08PM -0600, Ross Zwisler wrote:
> > > Add locking to ensure that DAX faults are isolated from ext2 operations
> >
t the patch below.
-Dave.
--
Dave Chinner
da...@fromorbit.com
xfs: stats are no longer dependent on CONFIG_PROC_FS
From: Dave Chinner
So we need to fix the makefile to understand this, otherwise build
errors with CONFIG_PROC_FS=n occur.
Reported-by: Jim Davis
Signed-off-by: Dave Chinner
--
On Tue, Oct 13, 2015 at 02:08:28PM -0700, Jim Davis wrote:
> On Tue, Oct 13, 2015 at 1:41 PM, Dave Chinner wrote:
> > On Tue, Oct 13, 2015 at 09:41:25AM -0700, Jim Davis wrote:
> >> Building with the attached random configuration file,
> >>
> >> fs/built-i
>
> This change is based on a similar outstanding patch for XFS from Dave
> Chinner entitled "xfs: add ->pfn_mkwrite support for DAX".
>
> Signed-off-by: Ross Zwisler
> Cc: Dave Chinner
> ---
> fs/dax.c | 13 +++--
> 1 file changed, 11 insertions(+
et implementation was retarded.
>
> One should spin on the variable with a load, not a rmw.
>
> While there, remove the queued from the name, as the lock isn't queued
> at all, but a simple test-and-set.
>
> Reported-by: Dave Chinner
> Suggested-by: Linus Torvald
On Fri, Sep 04, 2015 at 01:32:33PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 04, 2015 at 06:12:34PM +1000, Dave Chinner wrote:
> > You probably don't even need a VM to reproduce it - that would
> > certainly be an interesting counterpoint if it didn't
>
> Eve
sh entire file on dio read/write to cached file
Darrick J. Wong (2):
libxfs: readahead of dir3 data blocks should use the read verifier
libxfs: bad magic number should set da block buffer error
Dave Chinner (20):
xfs: call dax_fault on read page faults for DAX
xfs: remote attribute
On Wed, Oct 14, 2015 at 10:40:25AM +0200, Jan Kara wrote:
> On Wed 14-10-15 16:25:50, Dave Chinner wrote:
> > On Tue, Oct 13, 2015 at 04:25:36PM -0600, Ross Zwisler wrote:
> > > Update dax_pfn_mkwrite() so that it validates i_size before returning.
> > > This is necess
ext+0x1f36a0): undefined reference to `xfsstats'
Already been reported and fixed, just haven't pushed the patch yet.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to major
lities time to pick
up kernels and userspace pacakges that support the new feature
before the average user will encounter it
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo
; it for the merge window.
>
> ===
> for-4.4/dax-fixes:
> ===
...
> Dave Chinner (5):
> xfs: fix inode size update overflow in xfs_map_direct()
> xfs: introduce BMAPI_ZERO for allocating zeroed extents
> xfs: Don't use unwr
On Tue, Oct 20, 2015 at 05:31:18PM -0700, Dan Williams wrote:
> On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner wrote:
> > On Tue, Oct 20, 2015 at 11:31:45PM +, Williams, Dan J wrote:
> >> Here is a status summary of the topic-branches nvdimm.git is tracking
> >>
On Tue, Sep 01, 2015 at 09:19:45PM -0600, Ross Zwisler wrote:
> On Wed, Sep 02, 2015 at 08:21:20AM +1000, Dave Chinner wrote:
> > Which means applications that should "just work" without
> > modification on DAX are now subtly broken and don't actually
> >
On Wed, Sep 02, 2015 at 12:13:21PM +0300, Kirill A. Shutemov wrote:
> On Wed, Sep 02, 2015 at 08:49:22AM +1000, Dave Chinner wrote:
> > On Tue, Sep 01, 2015 at 01:08:04PM +0300, Kirill A. Shutemov wrote:
> > > On Tue, Sep 01, 2015 at 09:38:03AM +1000, Dave Chinner wrote:
>
2557190
So the problem is definitely the queued spinlock...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ker
On Thu, Sep 03, 2015 at 11:39:21PM -0700, Linus Torvalds wrote:
> On Thu, Sep 3, 2015 at 10:48 PM, Dave Chinner wrote:
> >
> > When I turned spinlock debugging off on 4.2 to get some perf numbers
> > a request from Linus, I got this:
>
> [ ugly numbers deleted ]
&
On Fri, Sep 04, 2015 at 09:39:17AM +0200, Peter Zijlstra wrote:
> On Thu, Sep 03, 2015 at 11:39:21PM -0700, Linus Torvalds wrote:
> > On Thu, Sep 3, 2015 at 10:48 PM, Dave Chinner wrote:
> > >
> > > When I turned spinlock debugging off on 4.2 to get some perf numbers
&g
On Fri, Sep 04, 2015 at 05:11:43PM +1000, Dave Chinner wrote:
> On Thu, Sep 03, 2015 at 11:39:21PM -0700, Linus Torvalds wrote:
> > There doesn't seem to be anything even remotely strange going on in that
> > area.
> >
> > Is this a PARAVIRT configur
On Fri, Sep 04, 2015 at 01:32:33PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 04, 2015 at 06:12:34PM +1000, Dave Chinner wrote:
> > You probably don't even need a VM to reproduce it - that would
> > certainly be an interesting counterpoint if it didn't
>
> Eve
gt; other things, so it's not suitable for us.
You don't want to do writeback from the syscall, right? i.e. you'd
like to expire the inode behind the fd, and schedule background
writeback to run on it immediately?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ges that
need to be committed and then write protected when fsync() is called
after write()...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More maj
On Mon, Oct 26, 2015 at 11:48:06AM +0900, Dan Williams wrote:
> On Mon, Oct 26, 2015 at 6:22 AM, Dave Chinner wrote:
> > On Thu, Oct 22, 2015 at 11:08:18PM +0200, Jan Kara wrote:
> >> Ugh2: Now I realized that DAX mmap isn't safe wrt fs freezing even for
> >> f
On Mon, Oct 26, 2015 at 05:56:30PM +0900, Dan Williams wrote:
> On Mon, Oct 26, 2015 at 3:23 PM, Dave Chinner wrote:
> > Also, DAX access isn't a property of mmap - it's a property
> > of the inode. We cannot do DAX access via mmap while mixing page
> > cache based
This reverts commit 843172978bb92997310d2f7fbc172ece423cfc02.
---
fs/dax.c| 33 -
mm/memory.c | 11 +++
2 files changed, 19 insertions(+), 25 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 400fe95..3994a2b 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -2
Hi folks,
As discussed in the recent thread about problems with DAX locking:
http://www.gossamer-threads.com/lists/linux/kernel/2264090?do=post_view_threaded
I said that I'd post the patch set that fixed the problems for XFS
as soon as I had something sane and workable. That's what this
series i
From: Dave Chinner
->pfn_mkwrite support is needed so that when a page with allocated
backing store takes a write fault we can check that the fault has
not raced with a truncate and is pointing to a region beyond the
current end of file.
This also allows us to update the timestamp on the in
From: Dave Chinner
To enable DAX to do atomic allocation of zeroed extents, we need to
drive the block zeroing deep into the allocator. Because
xfs_bmapi_write() can return merged extents on allocation that were
only partially allocated (i.e. requested range spans allocated and
hole regions
From: Dave Chinner
For DAX, we are now doing block zeroing and
we are updating the file size during allocation. This means we no
longer need an IO completion callback to do these things, so remove
the completion callbacks from the __dax_fault and __dax_mkwrite
calls.
Signed-off-by: Dave Chinner
From: Dave Chinner
Both direct IO and DAX pass an offset and count into get_blocks that
will overflow a s64 variable when an IO goes into the last supported
block in a file (i.e. at offset 2^63 - 1FSB bytes). This can be seen
from the tracing:
xfs_get_blocks_alloc: [...] offset
From: Dave Chinner
DAX has a page fault serialisation problem with block allocation.
Because it allows concurrent page faults and does not have a page
lock to serialise faults to the same page, it can get two concurrent
faults to the page that race.
When two read faults race, this isn't a
This reverts commit 46c043ede4711e8d598b9d63c5616c1fedb0605e.
---
fs/dax.c| 36
mm/memory.c | 11 +--
2 files changed, 25 insertions(+), 22 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 7ae6df7..400fe95 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@
On Thu, Oct 01, 2015 at 02:27:29PM -0600, Ross Zwisler wrote:
> On Thu, Oct 01, 2015 at 05:46:33PM +1000, Dave Chinner wrote:
> > This reverts commit 46c043ede4711e8d598b9d63c5616c1fedb0605e.
> > ---
> > fs/dax.c| 36
On Thu, Oct 01, 2015 at 02:31:21PM -0600, Ross Zwisler wrote:
> On Thu, Oct 01, 2015 at 05:46:32PM +1000, Dave Chinner wrote:
> > Hi folks,
> >
> > As discussed in the recent thread about problems with DAX locking:
> >
> > http://www.gossamer-threads.
d for fast path allocation with slowdowns
as we near ENOSPC in allocation routines. It gets harder to find
contiguous free space, files get more fragmented, IO takes longer
because we seek more, etc. Hence we accept that performance slows
down as as the need for precision increases as we near E
On Sun, Aug 26, 2018 at 04:53:12PM -0400, Waiman Long wrote:
> v1->v2:
> - For patch 1, remove wake_q_empty() & add task_in_wake_q().
> - Rewrite patch 2 after comments from Dave Chinner and break it down
>to 2 separate patches. Now the original xfs logic was kept. The
&g
eup contention go
away? Can you please test both of these things and report the
results so we can properly evaluate the impact of these changes?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Mon, Aug 27, 2018 at 12:39:06AM -0700, Christoph Hellwig wrote:
> On Mon, Aug 27, 2018 at 10:21:34AM +1000, Dave Chinner wrote:
> > tl; dr: Once you pass a certain point, ramdisks can be *much* slower
> > than SSDs on journal intensive workloads like AIM7. Hence it would be
>
On Mon, Aug 27, 2018 at 11:34:13AM -0400, Waiman Long wrote:
> On 08/26/2018 08:21 PM, Dave Chinner wrote:
> > On Sun, Aug 26, 2018 at 04:53:14PM -0400, Waiman Long wrote:
> >> The current log space reservation code allows multiple wakeups of the
> >> same sleeping waite
e've had enough recent bugs to deal with from shrinkers being
called before the filesystem is set up and from trying to handle
allocation errors during setup. Do we really want to make shrinker
shutdown just as prone to mismanagement and subtle, hard to hit
bugs? I don't think we do - unmount is simply not a critical
performance path.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
areful(&log->l_reserve_head.waiters)) {
> @@ -1086,8 +1110,10 @@
>
> spin_lock(&log->l_reserve_head.lock);
> free_bytes = xlog_space_left(log, &log->l_reserve_head.grant);
> - xlog_grant_head_wake(log, &log->l_reserve_head, &free_bytes);
> + xlog_grant_head_wake(log, &log->l_reserve_head, &free_bytes,
> + &wakeq);
> spin_unlock(&log->l_reserve_head.lock);
> + wake_up_q(&wakeq);
> }
> }
Ok, what about xlog_grant_head_wake_all()? You didn't convert that
to use wake queues, and so that won't remove tickets for the grant
head waiter list, and so those tasks will never get out of the new
inner loop you added to xlog_grant_head_wait(). That means
filesystem shutdowns will just hang the filesystem and leave it
unmountable. Did you run this through fstests?
Cheers,
Dave
--
Dave Chinner
da...@fromorbit.com
I'll update the fsmark
aio patches I have and retest this. The code looks pretty similar to
the last "generic aio fsync" patch I wrote, so I'm guessing that the
results will be pretty similar, too.
It would be good to finally get this implemented in the kernel...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Tue, Jan 09, 2018 at 09:10:54AM -0500, Jeff Layton wrote:
> From: Jeff Layton
>
> Signed-off-by: Jeff Layton
> Acked-by: Darrick J. Wong
Looks ok, but I haven't tested it at all.
Acked-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
On Tue, Jan 09, 2018 at 09:10:57AM -0500, Jeff Layton wrote:
> From: Jeff Layton
>
> If XFS_ILOG_CORE is already set then go ahead and increment it.
>
> Signed-off-by: Jeff Layton
> Acked-by: Darrick J. Wong
Acked-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
hg as the new
> "old" value and try again.
>
> This method allows us to avoid incrementing the counter on writes (and
> dirtying the metadata) under typical workloads. We only need to increment
> if it has been queried since it was last changed.
>
> Signed-off-by: Jef
like they are simple often
have subtle dependencies in them that automated backports won't ever
be able to understand, and if we don't get that right, we break
stuff.
Filesystems aren't like drivers or memory management - you can't
reboot to fix a filesystem corruption or data
On Fri, Mar 23, 2018 at 03:39:53PM +0300, Kirill Tkhai wrote:
> On 23.03.2018 02:46, Dave Chinner wrote:
> > On Thu, Mar 22, 2018 at 07:52:37PM +0300, Kirill Tkhai wrote:
> >> Here is the problem I'm solving: https://lkml.org/lkml/2018/3/21/365.
> >
> > Oh, fina
On Thu, Apr 05, 2018 at 08:54:50PM +0200, Dmitry Vyukov wrote:
> On Tue, Apr 3, 2018 at 6:38 AM, Dave Chinner wrote:
> > On Mon, Apr 02, 2018 at 07:01:02PM -0700, syzbot wrote:
> >> Hello,
> >>
> >> syzbot hit the following crash on upstream commit
> >
:-)
>
> Not really ... syzbot caught it Monday evening ;-)
Rather than arguing over who reported it first, I think that time
would be better spent reflecting on why the syzbot report was
completely ignored until *after* Ted diagnosed the issue
independently and Waiman had already fixed it
Clearly there is scope for improvement here.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Thu, Apr 05, 2018 at 05:13:25PM -0700, Eric Biggers wrote:
> On Fri, Apr 06, 2018 at 08:32:26AM +1000, Dave Chinner wrote:
> > On Wed, Apr 04, 2018 at 08:24:54PM -0700, Matthew Wilcox wrote:
> > > On Wed, Apr 04, 2018 at 11:22:00PM -0400, Theodore Y. Ts'o wrote:
> >
x.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F
as that will tell us what code paths are executing on inode
allocation.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Mon, Mar 19, 2018 at 02:06:01PM +0300, Kirill Tkhai wrote:
> On 17.03.2018 00:39, Dave Chinner wrote:
> > On Fri, Mar 16, 2018 at 11:55:30AM +0300, Kirill Tkhai wrote:
> >> On 16.03.2018 02:03, Dave Chinner wrote:
> >>> On Thu, Mar 15, 2018 at 10:28:43PM +0300,
On Tue, Mar 20, 2018 at 04:15:16PM +0300, Kirill Tkhai wrote:
> On 20.03.2018 03:18, Dave Chinner wrote:
> > On Mon, Mar 19, 2018 at 02:06:01PM +0300, Kirill Tkhai wrote:
> >> On 17.03.2018 00:39, Dave Chinner wrote:
> > Actually, it is fair, because:
> >
>
On Wed, Mar 21, 2018 at 07:15:14PM +0300, Kirill Tkhai wrote:
> On 20.03.2018 17:34, Dave Chinner wrote:
> > On Tue, Mar 20, 2018 at 04:15:16PM +0300, Kirill Tkhai wrote:
> >> On 20.03.2018 03:18, Dave Chinner wrote:
> >>> On Mon, Mar 19, 2018 at 02:06:01PM +0300,
issues...
> Can't we call shrink of shared objects only for top memcg? Something like
> this:
What's a "shared object", and how is it any different to a normal
slab cache object?
CHeers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Wed, Sep 26, 2018 at 07:24:26PM +0100, Alan Cox wrote:
> On Wed, 26 Sep 2018 11:33:29 +1000
> Dave Chinner wrote:
>
> > On Tue, Sep 25, 2018 at 08:51:50PM -0400, TongZhang wrote:
> > > Hi,
> > >
> > > I'm bringing up this issue again to let o
On Wed, Sep 26, 2018 at 09:23:03AM -0400, Stephen Smalley wrote:
> On 09/25/2018 09:33 PM, Dave Chinner wrote:
> >On Tue, Sep 25, 2018 at 08:51:50PM -0400, TongZhang wrote:
> >>Hi,
> >>
> >>I'm bringing up this issue again to let of LSM developers know t
On Fri, Sep 28, 2018 at 07:23:42AM +1000, James Morris wrote:
> On Thu, 27 Sep 2018, Dave Chinner wrote:
>
> > Sure, but there are so many CAP_SYS_ADMIN-only ioctls in the kernel
> > that have no LSM coverage that this is not an isolated problem that
> > people setting
On Thu, Nov 29, 2018 at 01:00:59AM -0500, Sasha Levin wrote:
> From: Dave Chinner
>
> [ Upstream commit b450672fb66b4a991a5b55ee24209ac7ae7690ce ]
>
> If we are doing sub-block dio that extends EOF, we need to zero
> the unused tail of the block to initialise the data in it
On Thu, Nov 29, 2018 at 12:55:43AM -0500, Sasha Levin wrote:
> From: Dave Chinner
>
> [ Upstream commit b450672fb66b4a991a5b55ee24209ac7ae7690ce ]
>
> If we are doing sub-block dio that extends EOF, we need to zero
> the unused tail of the block to initialise the data in it
ient to regression test
fixes that, in some cases, took hundreds of millions of fsx ops to
expose.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Thu, Nov 29, 2018 at 01:47:56PM +0100, Greg KH wrote:
> On Thu, Nov 29, 2018 at 11:14:59PM +1100, Dave Chinner wrote:
> >
> > Cherry picking only one of the 50-odd patches we've committed into
> > late 4.19 and 4.20 kernels to fix the problems we've found r
columns is preferred" but they are wrong.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
stack traces. It flattens them way too much to
be able to tell how we got to a specific location in the code.
In reality, being able to find problems quickly and efficiently is
far more important to us than being able to run everything at
ludicrous speed
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Mon, Nov 12, 2018 at 02:30:01PM -0800, Joe Perches wrote:
> On Tue, 2018-11-13 at 08:45 +1100, Dave Chinner wrote:
> > On Mon, Nov 12, 2018 at 02:12:08PM -0600, Eric Sandeen wrote:
> > > On 11/10/18 7:21 PM, Joe Perches wrote:
> > > > Reduce total object size quit
On Mon, Nov 12, 2018 at 08:54:10PM -0500, Theodore Y. Ts'o wrote:
> On Tue, Nov 13, 2018 at 12:18:05PM +1100, Dave Chinner wrote:
> > I'm not interested in making code fast if distro support engineers
> > can't debug problems on user systems easily. Optim
On Mon, Nov 12, 2018 at 08:23:42PM -0800, Joe Perches wrote:
> On Tue, 2018-11-13 at 14:09 +1100, Dave Chinner wrote:
> > On Mon, Nov 12, 2018 at 08:54:10PM -0500, Theodore Y. Ts'o wrote:
> > > On Tue, Nov 13, 2018 at 12:18:05PM +1100, Dave Chinner wrote:
> > > >
do a copy-on-write operation to break physical data
sharing and so the page with the file data in it physically changes
during ->page_mkwrite (because DAX). Hence we need to restart the
page fault to map the new page correctly because the file no longer
points at the page that was originally faulted.
With this stashed-page-and-retry mechanism implemented for
->page_mkwrite, we could stash the new page in the vmf and tell the
fault to retry, and everything would just work. Without
->page_mkwrite support, it's just not that interesting and I have
higher priority things to deal with right now
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Fri, Nov 30, 2018 at 09:22:03AM +0100, Greg KH wrote:
> On Fri, Nov 30, 2018 at 09:40:19AM +1100, Dave Chinner wrote:
> > On Thu, Nov 29, 2018 at 01:47:56PM +0100, Greg KH wrote:
> > > On Thu, Nov 29, 2018 at 11:14:59PM +1100, Dave Chinner wrote:
> > > >
> >
On Fri, Nov 30, 2018 at 05:14:41AM -0500, Sasha Levin wrote:
> On Fri, Nov 30, 2018 at 09:22:03AM +0100, Greg KH wrote:
> >On Fri, Nov 30, 2018 at 09:40:19AM +1100, Dave Chinner wrote:
> >>I stopped my tests at 5 billion ops yesterday (i.e. 20 billion ops
> >>aggrega
On Sat, Dec 01, 2018 at 02:49:09AM -0500, Sasha Levin wrote:
> On Sat, Dec 01, 2018 at 08:50:05AM +1100, Dave Chinner wrote:
> >On Fri, Nov 30, 2018 at 05:14:41AM -0500, Sasha Levin wrote:
> >>On Fri, Nov 30, 2018 at 09:22:03AM +0100, Greg KH wrote:
> >>>On Fri, No
ituation gracefully -
this is the appropriate way to handle incorrect calling contexts.
There is absolutely no good reason to panic production kernels
in situations like this.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
ontexts. But
something is clearly getting screwed up and the trigger is an OOM
kill event.
Anyone got any ideas on how to go about debugging this?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
s, but the fact is modifying sysctl in this way exposes
it to a whole bunch of stuff sysctl doesn't understand, shouldn't be
accessing and/or trying modify. i.e. sysctl is disturbingly dumb,
and it gets away with it because of it's restricted scope and API
presented by /proc/sys.
e access to."
I think it's also worth making a note about recursive/nested
save/restore stacking, because it's not clear from this description
that this is allowed and will work as long as inner save/restore
calls are fully nested inside outer save/restore contexts.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
make removable media
> reasonably safe from privilege escalation attacks.
>
> There is enough code in most filesystems that I don't know what our
> chances of locking down very many of them are. But I figure a few more
> of them are possible.
I'm not sure we need to - fus
On Fri, May 25, 2018 at 10:16:24AM +0200, Michal Hocko wrote:
> On Fri 25-05-18 08:17:15, Dave Chinner wrote:
> > On Thu, May 24, 2018 at 01:43:41PM +0200, Michal Hocko wrote:
> [...]
> > > +FS/IO code then simply calls the appropriate save function right at the
> >
On Fri, May 11, 2018 at 10:59:53AM +0200, Dmitry Vyukov wrote:
> On Thu, May 10, 2018 at 1:22 AM, Dave Chinner wrote:
> > On Wed, May 09, 2018 at 10:43:05AM +0200, Dmitry Vyukov wrote:
> >> Does "xfstests fuzzing infrastructure" use coverage-guidance?
> >
On Tue, May 29, 2018 at 09:34:35PM -0500, Eric W. Biederman wrote:
> Dave Chinner writes:
>
> > Yeah, the are some fairly big process and policy things that
> > need to be decided here. Not just at the kernel level, but at
> > distro and app infrastructure level too.
btrfs ioctl years ago and there are several dedupe applications out
there that use it. That's why we pulled it up to the vfs rather than
invent a new one and have to wait years for apps to start using
it...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
gt; that array. If the memory isn't vmapped, maybe the caller could pass
> an array pointer like XFS does, or we could require them to pass GFP flags
> to allocate a new array.
We have code in XFS to avoid allocating the array for the common
case - it ends up embedded in the struct xfs_buf instead and so we
avoid needing and extra alloc/free for every single buffer in the
fast path. Hence I'd prefer the interface lets the caller to supply
the result array, similar to the way callers provide their own
pagevecs for bulk page lookup functions...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
ndle that case in the put_user_page()
> function to properly dirty the page without causing filesystem
> freak out.
I'm pretty sure you can't call ->page_mkwrite() from
put_user_page(), so I don't think this is workable at all.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Wed, Dec 12, 2018 at 04:59:31PM -0500, Jerome Glisse wrote:
> On Thu, Dec 13, 2018 at 08:46:41AM +1100, Dave Chinner wrote:
> > On Wed, Dec 12, 2018 at 10:03:20AM -0500, Jerome Glisse wrote:
> > > On Mon, Dec 10, 2018 at 11:28:46AM +0100, Jan Kara wrote:
> > > > On
ed to page->private or not.
Hence it looks to me like the migration code is making invalid
assumptions about PagePrivate inferring reference counts and so the
migration code needs to be fixed. Requiring filesystems to work
around invalid assumptions in the migration code is a sure recipe
for
On Wed, Dec 12, 2018 at 09:02:29PM -0500, Jerome Glisse wrote:
> On Thu, Dec 13, 2018 at 11:51:19AM +1100, Dave Chinner wrote:
> > On Wed, Dec 12, 2018 at 04:59:31PM -0500, Jerome Glisse wrote:
> > > On Thu, Dec 13, 2018 at 08:46:41AM +1100, Dave Chinner wrote:
> > > &
On Mon, Dec 17, 2018 at 10:34:43AM -0800, Matthew Wilcox wrote:
> On Mon, Dec 17, 2018 at 01:11:50PM -0500, Jerome Glisse wrote:
> > On Mon, Dec 17, 2018 at 08:58:19AM +1100, Dave Chinner wrote:
> > > Sure, that's a possibility, but that doesn't close off any race
&g
On Tue, Dec 18, 2018 at 11:33:06AM +0100, Jan Kara wrote:
> On Mon 17-12-18 08:58:19, Dave Chinner wrote:
> > On Fri, Dec 14, 2018 at 04:43:21PM +0100, Jan Kara wrote:
> > > Hi!
> > >
> > > On Thu 13-12-18 08:46:41, Dave Chinner wrote:
> > > >
a to
userspace.
Putting the merkel tree somewhere else in the filesystem metadata
and providing a separate API to manipulate it avoids this problem.
It allows filesystems to keep their internal metadata and
security-related verification information in a separate channel (and
trust path) that is completely out of user data/access scope.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Tue, Dec 18, 2018 at 08:03:29PM -0700, Jason Gunthorpe wrote:
> On Wed, Dec 19, 2018 at 10:42:54AM +1100, Dave Chinner wrote:
>
> > Essentially, what we are talking about is how to handle broken
> > hardware. I say we should just brun it with napalm and thermite
> > (i.
On Wed, Dec 19, 2018 at 02:30:05PM -0500, Theodore Y. Ts'o wrote:
> On Wed, Dec 19, 2018 at 01:19:53PM +1100, Dave Chinner wrote:
> > Putting metadata in user files beyond EOF doesn't work with XFS's
> > post-EOF speculative allocation algorithms.
> >
> &g
On Wed, Dec 19, 2018 at 12:35:40PM +0100, Jan Kara wrote:
> On Wed 19-12-18 21:28:25, Dave Chinner wrote:
> > On Tue, Dec 18, 2018 at 08:03:29PM -0700, Jason Gunthorpe wrote:
> > > On Wed, Dec 19, 2018 at 10:42:54AM +1100, Dave Chinner wrote:
> > >
> > > >
On Fri, Dec 14, 2018 at 04:43:21PM +0100, Jan Kara wrote:
> Hi!
>
> On Thu 13-12-18 08:46:41, Dave Chinner wrote:
> > On Wed, Dec 12, 2018 at 10:03:20AM -0500, Jerome Glisse wrote:
> > > On Mon, Dec 10, 2018 at 11:28:46AM +0100, Jan Kara wrote:
> > > > On
per inode address
space" as using volatile RAM copies via the page cache, except
the struct pages point back to the same physical location rather
than having their own temporary, volatile copy of the data.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
mming involved at all...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Mon, Jan 07, 2019 at 05:41:39PM -0500, Waiman Long wrote:
> On 01/07/2019 05:32 PM, Dave Chinner wrote:
> > On Mon, Jan 07, 2019 at 10:12:56AM -0500, Waiman Long wrote:
> >> As newer systems have more and more IRQs and CPUs available in their
> >> system, the perfor
syscall implementation change that
was extremely likely to break userspace you'd be shouting at them
that "we don't break userspace"
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
501 - 600 of 2158 matches
Mail list logo
