On Sat, 23 Feb 2008, Al Viro wrote:
On Tue, Feb 19, 2008 at 05:04:38AM +0100, Arnd Bergmann wrote:
With most of debugfs now copied to generic code in libfs,
we can remove the original copy and replace it with thin
wrappers around libfs.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
On Sat, 16 Feb 2008, Erez Zadok wrote:
Check out my latest set of patches (which correspond to release 2.2.4 of
Unionfs). Thanks to your info and the patch, I was able to trigger several
races more frequently, and fix them. I've tested my code with make -j N
(for N=4 and N=20), on a 4 cpu
Hi Erez,
Aside from the occasional unionfs: new lower inode mtime messages
on directories (which I've got into the habit of ignoring now), the
only problem I'm still suffering with unionfs over tmpfs (not tested
any other fs's below it recently) is oops in unionfs_copy_attr_times.
I believe I'm
]
Good find! You got me very worried, how this escaped testing before.
Presumed explanation: it hasn't been needed beyond s390, which has no
CONFIG_HIGHMEM; and it has never been tested with CONFIG_DEBUG_VM on.
Acked-by: Hugh Dickins [EMAIL PROTECTED]
But I haven't tested it either: let's wait
On Tue, 13 Nov 2007, Erez Zadok wrote:
I posted all of these patches just now. You're CC'ed. Hopefully Andrew can
pull from my unionfs.git branch soon.
You also reported in your previous emails some hangs/oopses while doing make
-j 20 in unionfs on top of a single tmpfs, using -mm.
On Fri, 9 Nov 2007, Erez Zadok wrote:
In message [EMAIL PROTECTED], Hugh Dickins writes:
Three, I believe you need to add a flush_dcache_page(lower_page)
after the copy_highpage(lower_page): some architectures will need
that to see the new data if they have lower_page mapped (though I
On Fri, 9 Nov 2007, Erez Zadok wrote:
In message [EMAIL PROTECTED], Hugh Dickins writes:
One, I think you would be safer to do a set_page_dirty(lower_page)
before your clear_page_dirty_for_io(lower_page). I know that sounds
silly, but see Linus' Yes, Virginia comment
[Dave, I've Cc'ed you re handle_write_count_underflow, see below.]
On Wed, 31 Oct 2007, Erez Zadok wrote:
Hi Hugh, I've addressed all of your concerns and am happy to report that the
newly revised unionfs_writepage works even better, including under my
memory-pressure conditions. To
On Mon, 5 Nov 2007, Dave Hansen wrote:
Actually, I think your s/while/if/ change is probably a decent fix.
Any resemblance to a decent fix is purely coincidental.
Barring any other races, that loop should always have made progress on
mnt-__mnt_writers the way it is written. If we get to:
On Sun, 28 Oct 2007, Erez Zadok wrote:
I took your advise regarding ~(__GFP_FS|__GFP_IO), AOP_WRITEPAGE_ACTIVATE,
and such. I revised my unionfs_writepage and unionfs_sync_page, and tested
it under memory pressure: I have a couple of live CDs that use tmpfs and can
deterministically
On Fri, 26 Oct 2007, Neil Brown wrote:
On Thursday October 25, [EMAIL PROTECTED] wrote:
The patch looks like it makes perfect sense to me.
Great, thanks a lot for looking at it, Neil and Pekka.
Before the change, -writepage could return AOP_WRITEPAGE_ACTIVATE
without unlocking the page,
On Thu, 25 Oct 2007, Pekka Enberg wrote:
On 10/25/07, Hugh Dickins [EMAIL PROTECTED] wrote:
--- 2.6.24-rc1/mm/shmem.c 2007-10-24 07:16:04.0 +0100
+++ linux/mm/shmem.c2007-10-24 22:31:09.0 +0100
@@ -915,6 +915,21 @@ static int shmem_writepage(struct page
On Mon, 22 Oct 2007, Erez Zadok wrote:
In message [EMAIL PROTECTED], Hugh Dickins writes:
Only ramdisk and shmem have been returning AOP_WRITEPAGE_ACTIVATE.
Both of those set BDI_CAP_NO_WRITEBACK. ramdisk never returned it
if !wbc-for_reclaim. I contend that shmem shouldn't either
On Mon, 22 Oct 2007, Erez Zadok wrote:
What's the precise semantics of AOP_WRITEPAGE_ACTIVATE?
Sigh - not at you, at it! It's a secret that couldn't be kept secret,
a hack for tmpfs reclaim, let's just look forward to it going away.
Is it considered an error or not?
No, it's definitely not
source of AOP_WRITEPAGE_ACTIVATEs) is already careful
to check wbc-for_reclaim before returning it. Make the same check
in shmem_writepage, thereby sidestepping the page_mapped BUG also.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
Unionfs intends its own, third fix to these issues, checking
source of AOP_WRITEPAGE_ACTIVATEs) is already careful
to check wbc-for_reclaim before returning it. Make the same check
in shmem_writepage, thereby sidestepping the page_mapped BUG also.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
Unionfs intends its own, third fix to these issues, checking
Sorry for my delay, here are a few replies.
On Sun, 14 Oct 2007, Erez Zadok wrote:
In message [EMAIL PROTECTED], Pekka Enberg writes:
However, I don't think the mapping_cap_writeback_dirty() check in
__filemap_fdatawrite_range() works as expected when tmpfs is a lower
mount for an
On Sun, 14 Oct 2007, Erez Zadok wrote:
In message [EMAIL PROTECTED], Pekka J Enberg writes:
Look at mm/filemap.c:__filemap_fdatawrite_range(). You shouldn't be
calling unionfs_writepage() _at all_ if the lower mapping has
BDI_CAP_NO_WRITEBACK capability set. Perhaps something like the
On Mon, 15 Oct 2007, Pekka Enberg wrote:
I wonder whether _not setting_ BDI_CAP_NO_WRITEBACK implies that
-writepage() will never return AOP_WRITEPAGE_ACTIVATE for
!wbc-for_reclaim case which would explain why we haven't hit this bug
before. Hugh, Andrew?
Only ramdisk and shmem have been
On Sat, 13 Oct 2007, Pekka Enberg wrote:
On 10/12/07, Hugh Dickins [EMAIL PROTECTED] wrote:
But I keep suspecting that the answer might be the patch below (which
rather follows what drivers/block/rd.c is doing). I'm especially
worried that, rather than just AOP_WRITEPAGE_ACTIVATE being
On Thu, 11 Oct 2007, Ryan Finnie wrote:
On 10/11/07, Andrew Morton [EMAIL PROTECTED] wrote:
shit. That's a nasty bug. Really userspace should be testing for -1, but
the msync() library function should only ever return 0 or -1.
Does this fix it?
--- a/mm/page-writeback.c~a
+++
On Mon, 8 Oct 2007, Yan Zheng wrote:
The test for VM_CAN_NONLINEAR always fails
Good catch indeed. Though I was puzzled how we do nonlinear at all,
until I realized it's The test for not VM_CAN_NONLINEAR always fails.
It's not as serious as it appears, since code further down has been
added
On Thu, 20 Sep 2007, Christoph Lameter wrote:
On Thu, 20 Sep 2007, David Chinner wrote:
Disagree, the mmap side is not a little change.
That's not in the filesystem, though. ;)
And its really only a minimal change for some function to loop over all
4k pages and elsewhere index the
On Mon, 30 Jul 2007, Jan Blunck wrote:
Introduce white-out support to tmpfs.
Signed-off-by: Jan Blunck [EMAIL PROTECTED]
---
include/linux/shmem_fs.h |1
mm/shmem.c | 54
+++
2 files changed, 55 insertions(+)
I see
On Wed, 16 May 2007, Nick Piggin wrote:
Andrew Morton wrote:
I need to work out what to do with
mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch
mm-merge-populate-and-nopage-into-fault-fixes-nonlinear.patch
mm-merge-populate-and-nopage-into-fault-fixes-nonlinear-doc-fix.patch
On Thu, 17 May 2007, Nick Piggin wrote:
... and I don't want to change the
VM in a way that people are not unhappy with :)
I'm hoping you intended one less negative ;)
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More
On Mon, 14 May 2007, Bharata B Rao wrote:
From: Jan Blunck [EMAIL PROTECTED]
Subject: tmpfs whiteout support
Introduce whiteout support to tmpfs.
Signed-off-by: Jan Blunck [EMAIL PROTECTED]
Signed-off-by: Bharata B Rao [EMAIL PROTECTED]
---
mm/shmem.c |9 -
1 files
On Mon, 14 May 2007, Jan Blunck wrote:
On 5/14/07, Hugh Dickins [EMAIL PROTECTED] wrote:
/* Pretend that each entry is of this size in directory's i_size */
-#define BOGO_DIRENT_SIZE 20
+#define BOGO_DIRENT_SIZE 1
Why would that change be needed for whiteout support?
Good
On Wed, 7 Feb 2007, David Chinner wrote:
On Christoph's suggestion, take the guts of the proposed
xfs_vm_page_mkwrite function and implement it as a generic
core function as it used no specific XFS code at all.
This allows any filesystem to easily hook the -page_mkwrite()
VM callout to
On Thu, 8 Feb 2007, David Chinner wrote:
On Wed, Feb 07, 2007 at 01:00:28PM +, Hugh Dickins wrote:
I'm worried about concurrent truncation. Isn't it the case that
i_mutex is held when prepare_write and commit_write are normally
called? But not here when page_mkwrite is called
30 matches
Mail list logo
