Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2
On Mon, Mar 19, 2007 at 05:37:03PM +1100, Nick Piggin wrote:
David Chinner wrote:
+/*
+ * block_page_mkwrite() is not allowed to change the file size as it gets
+ * called from a page fault handler when a page is first dirtied. Hence
we must
+ * be careful to check for EOF conditions here. We set the page up
correctly
+ * for a written page which means we get ENOSPC checking when writing into
+ * holes and correct delalloc and unwritten extent mapping on filesystems
that
+ * support these features.
+ *
+ * We are not allowed to take the i_mutex here so we have to play games to
+ * protect against truncate races as the page could now be beyond EOF.
Because
+ * vmtruncate() writes the inode size before removing pages, once we have
the
+ * page lock we can determine safely if the page is beyond EOF. If it is
not
+ * beyond EOF, then the page is guaranteed safe against truncation until
we
+ * unlock the page.
+ */
+int
+block_page_mkwrite(struct vm_area_struct *vma, struct page *page,
+ get_block_t get_block)
+{
+struct inode *inode = vma-vm_file-f_path.dentry-d_inode;
+unsigned long end;
+loff_t size;
+int ret = -EINVAL;
+
+lock_page(page);
+size = i_size_read(inode);
+if ((page-mapping != inode-i_mapping) ||
+((page-index PAGE_CACHE_SHIFT) size)) {
+/* page got truncated out from underneath us */
+goto out_unlock;
+}
I see your explanation above, but I still don't see why this can't
just follow the conventional if (!page-mapping) check for truncation.
If the test happens to be performed after truncate concurrently
decreases i_size, then the blocks are going to get truncated by the
truncate afterwards anyway.
We have to read the inode size in the normal case so that we know if
the page is at EOF and is a partial page so we don't allocate past EOF in
block_prepare_write(). Hence it seems like a no-brainer to me to check
and error out on a page that we *know* is beyond EOF.
I can drop the check if you see no value in it - I just don't
like the idea of ignoring obvious boundary condition violations...
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Received a panic while closing the file.
Hi All,
I am writing a very simple file system for understanding purpose.
After mounting the file system, I am able to create file and read
write to the file. But, as soon as close the file, it is panicking.
I did some analysis and found that
My kernel has CONFIG_EPOLL enabled
struct file
{
.
.
#ifdef CONFIG_EPOLL
/* Used by fs/eventpoll.c to link all the hooks to this file */
struct list_headf_ep_links;
spinlock_t f_ep_lock;
#endif /* #ifdef CONFIG_EPOLL */
.
.
};
This is the stack trace of the oops
[ 4960.322635] EIP: [c01f3ffe] list_del+0xa/0x61 SS:ESP 0068:e9464f20
[ 4960.322511] [c0179342] eventpoll_release_file+0x25/0x69
[ 4960.322519] [c0155b0a] __fput+0xa3/0x15a
[ 4960.322526] [c0155bd8] fput+0x17/0x19
[ 4960.322532] [c0153610] filp_close+0x54/0x5c
[ 4960.322539] [c015e6e9] sys_dup2+0xd0/0xfc
[ 4960.322547] [c0103854] sysenter_past_esp+0x5d/0x99
eventpoll_release_file () functions result in the call to list_del()
void list_del(struct list_head *entry)
{
if (unlikely(entry-prev-next != entry)) { THIS IS THE LINE
WHERE OOPS IN HAPPENING
printk(KERN_ERR list_del corruption. prev-next should be %p,
but was %p\n, entry, entry-prev-next);
BUG();
}
if (unlikely(entry-next-prev != entry)) {
printk(KERN_ERR list_del corruption. next-prev should be %p,
but was %p\n, entry, entry-next-prev);
BUG();
}
__list_del(entry-prev, entry-next);
entry-next = LIST_POISON1;
entry-prev = LIST_POISON2;
}
This is the panic string
BUG: unable to handle kernel NULL pointer dereference at virtual
address
So, I think file-f_ep_links is not initialized in my code.
Can anyone please let me know the reason
Why event polls are used? and
What function should I call for initializing the file- f_ep_links list.?
Thanks and Regards,
Prasad.
ADDING OOPS IF REQUIRED FOR THE REFERENCE
Here is the oops msg.
[ 4960.322267] Inode Created : 17190 = test1BUG: unable to handle
kernel NULL pointer dereference at virtual address
[ 4960.322328] printing eip:
[ 4960.322332] c01f3ffe
[ 4960.322335] *pde =
[ 4960.322341] Oops: [#2]
[ 4960.322344] SMP
[ 4960.322350] Modules linked in: fs cpufreq_stats
cpufreq_ondemandfreq_table ac evdev thermal processor fan
[ 4960.322370] CPU: 1
[ 4960.322372] EIP: 0060:[c01f3ffe] Not tainted VLI
[ 4960.322376] EFLAGS: 00010282 (2.6.20 #8)
[ 4960.322386
] EIP is at list_del+0xa/0x61
[ 4960.322391] eax: f8868080 ebx: f8868044 ecx: edx:
e75ef5cc
[ 4960.322398] esi: f8868080 edi: ebp: e9464f30 esp:
e9464f20
[ 4960.322403] ds: 007b es: 007b ss: 0068
[ 4960.322409] Process bash (pid: 6062, ti=e9464000 task=f751b4f0
task.ti=e9464000)
[ 4960.322415] Stack: e75ef5cc e9464f30 c0344186 f8868044 e9464f48
c0179342 e75ef5cc 0008
[ 4960.322430]f599e03c e75ef5cc e9464f70 c0155b0a
e826b1cc dfff0988
[ 4960.322445]f599e03c e75ef5cc f7baaca8 e9464f78
c0155bd8 e9464f90 c0153610
[ 4960.322459] Call Trace:
[ 4960.322462] [c01048a2] show_trace_log_lvl+0x1a/0x2f
[ 4960.322472] [c0104954] show_stack_log_lvl+0x9d/0xa5
[ 4960.322481] [c0104af1] show_registers+0x195/0x26b
[ 4960.322489] [c0104ce0] die+0x119/0x21a
[ 4960.322496] [c034713d] do_page_fault+0x443/0x514
[ 4960.322504] [c034597c] error_code+0x7c/0x84
[ 4960.322511] [c0179342] eventpoll_release_file+0x25/0x69
[ 4960.322519] [c0155b0a] __fput+0xa3/0x15a
[ 4960.322526] [c0155bd8] fput+0x17/0x19
[ 4960.322532] [c0153610] filp_close+0x54/0x5c
[ 4960.322539] [c015e6e9] sys_dup2+0xd0/0xfc
[ 4960.322547] [c0103854] sysenter_past_esp+0x5d/0x99
[ 4960.322555] ===
[ 4960.322558] Code: 00 00 8d 4b 0c 8b 51 04 8d 46 0c e8 72 00 00 00
89 f8 e8 87 fe ff ff 83 c4 10 5b 5e 5f 5d c3 90 90 55 89 e5 53 83 ec
0c 8b 48 04 8b 11 39 c2 74 18 89 54 24 08 89 44 24 04 c7 04 24 92 37
3e c0
[ 4960.322635] EIP: [c01f3ffe] list_del+0xa/0x61 SS:ESP 0068:e9464f20
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2
On Mon, Mar 19, 2007 at 10:30:08AM +1100, David Chinner wrote: Generic page_mkwrite functionality. Filesystems that make use of the VM -page_mkwrite() callout will generally use the same core code to implement it. There are several tricky truncate-related issues that we need to deal with here as we cannot take the i_mutex as we normally would for these paths. These issues are not documented anywhere yet so block_page_mkwrite() seems like the best place to start. This will need some updates when -fault replaces -page_mkwrite. Nich, what's the plan for merging -fault? - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2
David Chinner wrote:
On Mon, Mar 19, 2007 at 05:37:03PM +1100, Nick Piggin wrote:
David Chinner wrote:
+block_page_mkwrite(struct vm_area_struct *vma, struct page *page,
+ get_block_t get_block)
+{
+ struct inode *inode = vma-vm_file-f_path.dentry-d_inode;
+ unsigned long end;
+ loff_t size;
+ int ret = -EINVAL;
+
+ lock_page(page);
+ size = i_size_read(inode);
+ if ((page-mapping != inode-i_mapping) ||
+ ((page-index PAGE_CACHE_SHIFT) size)) {
+ /* page got truncated out from underneath us */
+ goto out_unlock;
+ }
I see your explanation above, but I still don't see why this can't
just follow the conventional if (!page-mapping) check for truncation.
If the test happens to be performed after truncate concurrently
decreases i_size, then the blocks are going to get truncated by the
truncate afterwards anyway.
We have to read the inode size in the normal case so that we know if
the page is at EOF and is a partial page so we don't allocate past EOF in
block_prepare_write(). Hence it seems like a no-brainer to me to check
and error out on a page that we *know* is beyond EOF.
I can drop the check if you see no value in it - I just don't
like the idea of ignoring obvious boundary condition violations...
I would prefer it dropped, to be honest. I can see how the check does
pick up that corner case, however truncate is difficult enough (at
least, it has been an endless source of problems) that we want to keep
everyone else simple and have all the non-trivial stuff in truncate.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2
Nick Piggin wrote:
David Chinner wrote:
On Mon, Mar 19, 2007 at 05:37:03PM +1100, Nick Piggin wrote:
David Chinner wrote:
+block_page_mkwrite(struct vm_area_struct *vma, struct page *page,
+ get_block_t get_block)
+{
+struct inode *inode = vma-vm_file-f_path.dentry-d_inode;
+unsigned long end;
+loff_t size;
+int ret = -EINVAL;
+
+lock_page(page);
+size = i_size_read(inode);
+if ((page-mapping != inode-i_mapping) ||
+((page-index PAGE_CACHE_SHIFT) size)) {
+/* page got truncated out from underneath us */
+goto out_unlock;
+}
I see your explanation above, but I still don't see why this can't
just follow the conventional if (!page-mapping) check for truncation.
If the test happens to be performed after truncate concurrently
decreases i_size, then the blocks are going to get truncated by the
truncate afterwards anyway.
We have to read the inode size in the normal case so that we know if
the page is at EOF and is a partial page so we don't allocate past EOF in
block_prepare_write(). Hence it seems like a no-brainer to me to check
and error out on a page that we *know* is beyond EOF.
I can drop the check if you see no value in it - I just don't
like the idea of ignoring obvious boundary condition violations...
I would prefer it dropped, to be honest. I can see how the check does
pick up that corner case, however truncate is difficult enough (at
least, it has been an endless source of problems) that we want to keep
everyone else simple and have all the non-trivial stuff in truncate.
Hmm, actually on second thoughts it probably is reasonable to recheck
i_size under the page lock... we need to do similar in the nopage path
to close the nopage vs invalidate race.
However, the already-truncated test I think can just be !page-mapping:
there should be no way for the page mapping to change to something
other than NULL.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] sys_fallocate() system call
On Fri, Mar 16, 2007 at 04:21:03PM +0100, Heiko Carstens wrote: On Fri, Mar 16, 2007 at 08:01:01PM +0530, Amit K. Arora wrote: First of all, thanks for the overwhelming response! Based on the suggestions received, I have added a new parameter to the sys_fallocate() system call - an interger called mode, just after the fd. Now the system call looks like this: asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len) Currently we have two modes FA_ALLOCATE and FA_DEALLOCATE, for preallocation and deallocation of preallocated blocks respectively. More modes can be added, when required. And these modes can be renamed, since I am sure these are no way the best ones ! :) Attached below is the patch which implements this system call. It has been currently implemented and tested on i386, ppc64 and x86_64 architectures. I am facing some problems while trying to implement this on s390, and thus the delay. While I try to get it right on s390(x), we thought of posting this patch, so that we can save some time. Parallely we will work on getting the patch work on s390, and probably it will come as a separate patch. What's the problem you face on s390? If it's just the compat wrapper, you may look at sys_sync_file_range_wrapper. Or I will send a patch if needed. Hi Heiko, Yes, the problem was adding compat wrapper for this. I will appreciate your help in writing it. Only thing is that we might have to wait till the order of the arguments is decided upon. Thanks! -- Regards, Amit Arora - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] sys_fallocate() system call
On Sat, Mar 17, 2007 at 04:33:50PM +1100, Stephen Rothwell wrote: On Fri, 16 Mar 2007 20:01:01 +0530 Amit K. Arora [EMAIL PROTECTED] wrote: +asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len); --- linux-2.6.20.1.orig/include/asm-powerpc/systbl.h +++ linux-2.6.20.1/include/asm-powerpc/systbl.h @@ -305,3 +305,4 @@ SYSCALL_SPU(faccessat) COMPAT_SYS_SPU(get_robust_list) COMPAT_SYS_SPU(set_robust_list) COMPAT_SYS(move_pages) +SYSCALL(fallocate) It is going to need to be a COMPAT_SYS call in powerpc because 32 bit powerpc will pass the two loff_t's in pairs of registers while 64bit passes them in one register each. Ok. Will make that change, unless it is decided to pass each loff_t argument as two u32s. Thanks! -- Regards, Amit Arora - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] sys_fallocate() system call
On Mon, Mar 19, 2007 at 02:54:04PM +0530, Amit K. Arora wrote: On Fri, Mar 16, 2007 at 04:21:03PM +0100, Heiko Carstens wrote: On Fri, Mar 16, 2007 at 08:01:01PM +0530, Amit K. Arora wrote: asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len) Currently we have two modes FA_ALLOCATE and FA_DEALLOCATE, for preallocation and deallocation of preallocated blocks respectively. More modes can be added, when required. And these modes can be renamed, since I am sure these are no way the best ones ! :) Yes, the problem was adding compat wrapper for this. I will appreciate your help in writing it. Only thing is that we might have to wait till the order of the arguments is decided upon. Thanks! There is probably not much choice. If you want to stay with the loff_t arguments it won't work on 31-bit s390 or 32-bit powerpc dependent on the order of the arguments. So you should go for what Matthew Wilcox suggested: asmlinkage long sys_fallocate(int fd, int mode, u32 off_low, u32 off_high, u32 len_low, u32 len_high); That way it will work an all architectures and in addition no architecture has to do some magic to combine the splitted 64 bit arguments in compat mode. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] fs: remove duplicated iovec checking code v8
Where are several places where the same code used for iovec checks.
This patch just move this code to separate helper function, and replace
duplicated code with it. IMHO it is better because these are checks that
we want for all filesystems/drivers that use vectored I/O.
Signed-off-by: Dmitriy Monakhov [EMAIL PROTECTED]
---
fs/ntfs/file.c | 21 +++--
fs/read_write.c| 40
fs/xfs/linux-2.6/xfs_lrw.c | 22 +++---
include/linux/fs.h |3 +++
mm/filemap.c | 43 ++-
5 files changed, 55 insertions(+), 74 deletions(-)
diff --git a/fs/ntfs/file.c b/fs/ntfs/file.c
index dbbac55..2c672a4 100644
--- a/fs/ntfs/file.c
+++ b/fs/ntfs/file.c
@@ -2129,28 +2129,13 @@ static ssize_t ntfs_file_aio_write_nolock(struct kiocb
*iocb,
struct address_space *mapping = file-f_mapping;
struct inode *inode = mapping-host;
loff_t pos;
- unsigned long seg;
size_t count; /* after file limit checks */
ssize_t written, err;
count = 0;
- for (seg = 0; seg nr_segs; seg++) {
- const struct iovec *iv = iov[seg];
- /*
-* If any segment has a negative length, or the cumulative
-* length ever wraps negative then return -EINVAL.
-*/
- count += iv-iov_len;
- if (unlikely((ssize_t)(count|iv-iov_len) 0))
- return -EINVAL;
- if (access_ok(VERIFY_READ, iv-iov_base, iv-iov_len))
- continue;
- if (!seg)
- return -EFAULT;
- nr_segs = seg;
- count -= iv-iov_len; /* This segment is no good */
- break;
- }
+ err = generic_iovec_checks(iov, nr_segs, count, VERIFY_READ);
+ if (err)
+ return err;
pos = *ppos;
vfs_check_frozen(inode-i_sb, SB_FREEZE_WRITE);
/* We can write back this queue in page reclaim. */
diff --git a/fs/read_write.c b/fs/read_write.c
index 4d03008..22ec324 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -217,6 +217,46 @@ Einval:
return -EINVAL;
}
+/*
+ * Performs necessary iovec checks before doing a write
+ * @iov: io vector request
+ * @nr_segs: number of segments in the iovec
+ * @count: number of bytes to write
+ * @access_flags: type of access: %VERIFY_READ or %VERIFY_WRITE
+ *
+ * Adjust number of segments and amount of bytes to write (nr_segs should be
+ * properly initialized first). Returns appropriate error code that caller
+ * should return or zero in case that write should be allowed.
+ */
+int generic_iovec_checks(const struct iovec *iov,
+ unsigned long *nr_segs, size_t *count,
+ unsigned long access_flags)
+{
+ unsigned long seg;
+ size_t cnt = 0;
+ for (seg = 0; seg *nr_segs; seg++) {
+ const struct iovec *iv = iov[seg];
+
+ /*
+* If any segment has a negative length, or the cumulative
+* length ever wraps negative then return -EINVAL.
+*/
+ cnt += iv-iov_len;
+ if (unlikely((ssize_t)(cnt|iv-iov_len) 0))
+ return -EINVAL;
+ if (access_ok(access_flags, iv-iov_base, iv-iov_len))
+ continue;
+ if (seg == 0)
+ return -EFAULT;
+ *nr_segs = seg;
+ cnt -= iv-iov_len; /* This segment is no good */
+ break;
+ }
+ *count = cnt;
+ return 0;
+}
+EXPORT_SYMBOL(generic_iovec_checks);
+
static void wait_on_retry_sync_kiocb(struct kiocb *iocb)
{
set_current_state(TASK_UNINTERRUPTIBLE);
diff --git a/fs/xfs/linux-2.6/xfs_lrw.c b/fs/xfs/linux-2.6/xfs_lrw.c
index ff8d64e..9a11b00 100644
--- a/fs/xfs/linux-2.6/xfs_lrw.c
+++ b/fs/xfs/linux-2.6/xfs_lrw.c
@@ -639,7 +639,6 @@ xfs_write(
xfs_fsize_t isize, new_size;
xfs_iocore_t*io;
bhv_vnode_t *vp;
- unsigned long seg;
int iolock;
int eventsent = 0;
bhv_vrwlock_t locktype;
@@ -652,24 +651,9 @@ xfs_write(
vp = BHV_TO_VNODE(bdp);
xip = XFS_BHVTOI(bdp);
- for (seg = 0; seg segs; seg++) {
- const struct iovec *iv = iovp[seg];
-
- /*
-* If any segment has a negative length, or the cumulative
-* length ever wraps negative then return -EINVAL.
-*/
- ocount += iv-iov_len;
- if (unlikely((ssize_t)(ocount|iv-iov_len) 0))
- return -EINVAL;
- if (access_ok(VERIFY_READ, iv-iov_base, iv-iov_len))
-
Re: [PATCH 1/2] fs: remove duplicated iovec checking code v8
On Mon, Mar 19, 2007 at 10:49:01AM +0300, Dmitriy Monakhov wrote: Where are several places where the same code used for iovec checks. This patch just move this code to separate helper function, and replace duplicated code with it. IMHO it is better because these are checks that we want for all filesystems/drivers that use vectored I/O. Please move this into the common code path, so it's checked before entering the filesystem. This won't cover the calculating count until we have an iodesc/uio strcuture to pass it down, so feel free to add a tiny helper for that temporaily. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2
On Mon, Mar 19, 2007 at 09:11:31PM +1100, Nick Piggin wrote: I've got the patches in -mm now. I hope they will get merged when the the next window opens. I didn't submit the -page_mkwrite conversion yet, because I didn't have any callers to look at. It is is slightly less trivial than for nopage and nopfn, so having David's block_page_mkwrite is helpful. Yes. I was just wondering whether it makes more sense to do this functionality directly ontop of -fault instead of converting i over real soon. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] unionfs: sioq not __exit
From: Randy Dunlap [EMAIL PROTECTED]
stop_sioq() is called from both __init and __exit functions, so it
shouldn't be marked __exit.
Reported on the kernelnewbies mailing list, but no patch offered there.
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
fs/unionfs/sioq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.21-rc3-mm2.orig/fs/unionfs/sioq.c
+++ linux-2.6.21-rc3-mm2/fs/unionfs/sioq.c
@@ -40,7 +40,7 @@ int __init init_sioq(void)
return err;
}
-void __exit stop_sioq(void)
+void stop_sioq(void)
{
if (superio_workqueue)
destroy_workqueue(superio_workqueue);
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ROMFS: printk format warnings
From: Randy Dunlap [EMAIL PROTECTED] Field width and precision must be of type int. fs/romfs/super.c:513: warning: field width should have type 'int', but argument 2 has type 'size_t' fs/romfs/super.c:513: warning: field precision should have type 'int', but argument 3 has type 'size_t' Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- fs/romfs/super.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.21-rc3-mm2.orig/fs/romfs/super.c +++ linux-2.6.21-rc3-mm2/fs/romfs/super.c @@ -510,7 +510,7 @@ static int romfs_fill_super(struct super len = strnlen(rsb-name, ROMFS_MAXFN); if (!silent) printk(ROMFS: Mounting image '%*.*s' through %s\n, - len, len, rsb-name, storage); + (int)len, (int)len, rsb-name, storage); kfree(rsb); rsb = NULL; - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] reiserfs: proc support requires PROC_FS
From: Randy Dunlap [EMAIL PROTECTED] REISER_FS /proc option needs to depend on PROC_FS. fs/reiserfs/procfs.c: In function 'show_super': fs/reiserfs/procfs.c:134: error: 'reiserfs_proc_info_data_t' has no member named 'max_hash_collisions' fs/reiserfs/procfs.c:134: error: 'reiserfs_proc_info_data_t' has no member named 'breads' fs/reiserfs/procfs.c:135: error: 'reiserfs_proc_info_data_t' has no member named 'bread_miss' fs/reiserfs/procfs.c:135: error: 'reiserfs_proc_info_data_t' has no member named 'search_by_key' fs/reiserfs/procfs.c:136: error: 'reiserfs_proc_info_data_t' has no member named 'search_by_key_fs_changed' fs/reiserfs/procfs.c:136: error: 'reiserfs_proc_info_data_t' has no member named 'search_by_key_restarted' fs/reiserfs/procfs.c:137: error: 'reiserfs_proc_info_data_t' has no member named 'insert_item_restarted' fs/reiserfs/procfs.c:137: error: 'reiserfs_proc_info_data_t' has no member named 'paste_into_item_restarted' fs/reiserfs/procfs.c:138: error: 'reiserfs_proc_info_data_t' has no member named 'cut_from_item_restarted' fs/reiserfs/procfs.c:139: error: 'reiserfs_proc_info_data_t' has no member named 'delete_solid_item_restarted' fs/reiserfs/procfs.c:139: error: 'reiserfs_proc_info_data_t' has no member named 'delete_item_restarted' fs/reiserfs/procfs.c:140: error: 'reiserfs_proc_info_data_t' has no member named 'leaked_oid' fs/reiserfs/procfs.c:140: error: 'reiserfs_proc_info_data_t' has no member named 'leaves_removable' fs/reiserfs/procfs.c: In function 'show_per_level': fs/reiserfs/procfs.c:184: error: 'reiserfs_proc_info_data_t' has no member named 'balance_at' fs/reiserfs/procfs.c:185: error: 'reiserfs_proc_info_data_t' has no member named 'sbk_read_at' fs/reiserfs/procfs.c:186: error: 'reiserfs_proc_info_data_t' has no member named 'sbk_fs_changed' fs/reiserfs/procfs.c:187: error: 'reiserfs_proc_info_data_t' has no member named 'sbk_restarted' fs/reiserfs/procfs.c:188: error: 'reiserfs_proc_info_data_t' has no member named 'free_at' fs/reiserfs/procfs.c:189: error: 'reiserfs_proc_info_data_t' has no member named 'items_at' fs/reiserfs/procfs.c:190: error: 'reiserfs_proc_info_data_t' has no member named 'can_node_be_removed' fs/reiserfs/procfs.c:191: error: 'reiserfs_proc_info_data_t' has no member named 'lnum' fs/reiserfs/procfs.c:192: error: 'reiserfs_proc_info_data_t' has no member named 'rnum' fs/reiserfs/procfs.c:193: error: 'reiserfs_proc_info_data_t' has no member named 'lbytes' fs/reiserfs/procfs.c:194: error: 'reiserfs_proc_info_data_t' has no member named 'rbytes' fs/reiserfs/procfs.c:195: error: 'reiserfs_proc_info_data_t' has no member named 'get_neighbors' fs/reiserfs/procfs.c:196: error: 'reiserfs_proc_info_data_t' has no member named 'get_neighbors_restart' fs/reiserfs/procfs.c:197: error: 'reiserfs_proc_info_data_t' has no member named 'need_l_neighbor' fs/reiserfs/procfs.c:197: error: 'reiserfs_proc_info_data_t' has no member named 'need_r_neighbor' fs/reiserfs/procfs.c: In function 'show_bitmap': fs/reiserfs/procfs.c:224: error: 'reiserfs_proc_info_data_t' has no member named 'free_block' fs/reiserfs/procfs.c:225: error: 'reiserfs_proc_info_data_t' has no member named 'scan_bitmap' fs/reiserfs/procfs.c:226: error: 'reiserfs_proc_info_data_t' has no member named 'scan_bitmap' fs/reiserfs/procfs.c:227: error: 'reiserfs_proc_info_data_t' has no member named 'scan_bitmap' fs/reiserfs/procfs.c:228: error: 'reiserfs_proc_info_data_t' has no member named 'scan_bitmap' fs/reiserfs/procfs.c:229: error: 'reiserfs_proc_info_data_t' has no member named 'scan_bitmap' fs/reiserfs/procfs.c:230: error: 'reiserfs_proc_info_data_t' has no member named 'scan_bitmap' fs/reiserfs/procfs.c:230: error: 'reiserfs_proc_info_data_t' has no member named 'scan_bitmap' fs/reiserfs/procfs.c: In function 'show_journal': fs/reiserfs/procfs.c:384: error: 'reiserfs_proc_info_data_t' has no member named 'journal' fs/reiserfs/procfs.c:385: error: 'reiserfs_proc_info_data_t' has no member named 'journal' fs/reiserfs/procfs.c:386: error: 'reiserfs_proc_info_data_t' has no member named 'journal' fs/reiserfs/procfs.c:387: error: 'reiserfs_proc_info_data_t' has no member named 'journal' fs/reiserfs/procfs.c:388: error: 'reiserfs_proc_info_data_t' has no member named 'journal' fs/reiserfs/procfs.c:389: error: 'reiserfs_proc_info_data_t' has no member named 'journal' fs/reiserfs/procfs.c:390: error: 'reiserfs_proc_info_data_t' has no member named 'journal' fs/reiserfs/procfs.c:391: error: 'reiserfs_proc_info_data_t' has no member named 'journal' fs/reiserfs/procfs.c:392: error: 'reiserfs_proc_info_data_t' has no member named 'journal' fs/reiserfs/procfs.c:393: error: 'reiserfs_proc_info_data_t' has no member named 'journal' fs/reiserfs/procfs.c:394: error: 'reiserfs_proc_info_data_t' has no member named 'journal' fs/reiserfs/procfs.c:395: error: 'reiserfs_proc_info_data_t' has no member named 'journal' fs/reiserfs/procfs.c:395: error:
Re: [PATCH] unionfs: sioq not __exit
On Mon, Mar 19, 2007 at 03:22:26PM -0700, Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] stop_sioq() is called from both __init and __exit functions, so it shouldn't be marked __exit. Reported on the kernelnewbies mailing list, but no patch offered there. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] Applied. Thanks. Josef Jeff Sipek. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2
Christoph Hellwig wrote: On Mon, Mar 19, 2007 at 09:11:31PM +1100, Nick Piggin wrote: I've got the patches in -mm now. I hope they will get merged when the the next window opens. I didn't submit the -page_mkwrite conversion yet, because I didn't have any callers to look at. It is is slightly less trivial than for nopage and nopfn, so having David's block_page_mkwrite is helpful. Yes. I was just wondering whether it makes more sense to do this functionality directly ontop of -fault instead of converting i over real soon. I would personally prefer that, but I don't want to block David's patch from being merged if the -fault patches do not get in next cycle. If the fault patches do make it in first, then yes we should do the page_mkwrite conversion before merging David's patch. I'll keep an eye on it, and try to do the right thing. Thanks, Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: new-aops-1 for 2.6.21-rc3
On Thu, Mar 15, 2007 at 04:47:13PM -0700, Mark Fasheh wrote: On Thu, Mar 15, 2007 at 05:17:04PM +0100, Nick Piggin wrote: (excludes the OCFS2 patch that Mark sent, in anticipation of an update) Attached is said patch. I needed to export __grab_cache_page (ext2/ext3 also need this if they're to be built as modules), so a patch to do that is also attached. This passed some preliminary testing on a two node cluster I have here at Oracle. Thanks Mark, I've merged these. Nick - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
