[2.6 patch] make fs/buffer.c:cont_expand_zero() static
cont_expand_zero() can become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch has been sent on:
- 15 Jun 2007
--- linux-2.6.22-rc4-mm2/fs/buffer.c.old2007-06-14 01:51:08.0
+0200
+++ linux-2.6.22-rc4-mm2/fs/buffer.c2007-06-14 01:51:42.0 +0200
@@ -2181,8 +2181,8 @@
return err;
}
-int cont_expand_zero(struct file *file, struct address_space *mapping,
- loff_t pos, loff_t *bytes)
+static int cont_expand_zero(struct file *file, struct address_space *mapping,
+ loff_t pos, loff_t *bytes)
{
struct inode *inode = mapping-host;
unsigned blocksize = 1 inode-i_blkbits;
-
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
[2.6 patch] remove generic_commit_write()
This patch removes the obsolete and no longer used generic_commit_write().
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
fs/buffer.c | 18 --
include/linux/buffer_head.h |1 -
2 files changed, 19 deletions(-)
ef68a189129f02603fb49b09d331d1ea2fcd25da diff --git a/fs/buffer.c b/fs/buffer.c
index 9f55970..4f89fd9 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -2311,23 +2311,6 @@ int block_commit_write(struct page *page, unsigned from,
unsigned to)
return 0;
}
-int generic_commit_write(struct file *file, struct page *page,
- unsigned from, unsigned to)
-{
- struct inode *inode = page-mapping-host;
- loff_t pos = ((loff_t)page-index PAGE_CACHE_SHIFT) + to;
- __block_commit_write(inode,page,from,to);
- /*
-* No need to use i_size_read() here, the i_size
-* cannot change under us because we hold i_mutex.
-*/
- if (pos inode-i_size) {
- i_size_write(inode, pos);
- mark_inode_dirty(inode);
- }
- return 0;
-}
-
/*
* 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
@@ -3300,7 +3283,6 @@ EXPORT_SYMBOL(end_buffer_write_sync);
EXPORT_SYMBOL(file_fsync);
EXPORT_SYMBOL(fsync_bdev);
EXPORT_SYMBOL(generic_block_bmap);
-EXPORT_SYMBOL(generic_commit_write);
EXPORT_SYMBOL(generic_cont_expand_simple);
EXPORT_SYMBOL(init_buffer);
EXPORT_SYMBOL(invalidate_bdev);
diff --git a/include/linux/buffer_head.h b/include/linux/buffer_head.h
index 932eb02..82aa36c 100644
--- a/include/linux/buffer_head.h
+++ b/include/linux/buffer_head.h
@@ -225,7 +225,6 @@ int block_page_mkwrite(struct vm_area_struct *vma, struct
page *page,
get_block_t get_block);
void block_sync_page(struct page *);
sector_t generic_block_bmap(struct address_space *, sector_t, get_block_t *);
-int generic_commit_write(struct file *, struct page *, unsigned, unsigned);
int block_truncate_page(struct address_space *, loff_t, get_block_t *);
int file_fsync(struct file *, struct dentry *, int);
int nobh_write_begin(struct file *, struct address_space *,
-
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
[2.6 patch] make vfs_ioctl() static
This patch makes the needlessly global vfs_ioctl() static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
fs/ioctl.c |4 ++--
include/linux/fs.h |1 -
2 files changed, 2 insertions(+), 3 deletions(-)
18bc247a745a825238208f88fbe1b86ba1ef304e diff --git a/fs/ioctl.c b/fs/ioctl.c
index f32fbde..7db32b3 100644
--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -28,8 +28,8 @@
*
* Returns 0 on success, -errno on error.
*/
-long vfs_ioctl(struct file *filp, unsigned int cmd,
- unsigned long arg)
+static long vfs_ioctl(struct file *filp, unsigned int cmd,
+ unsigned long arg)
{
int error = -ENOTTY;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index b84b848..23528b8 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1919,7 +1919,6 @@ extern int vfs_stat_fd(int dfd, char __user *, struct
kstat *);
extern int vfs_lstat_fd(int dfd, char __user *, struct kstat *);
extern int vfs_fstat(unsigned int, struct kstat *);
-extern long vfs_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
extern int do_vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd,
unsigned long arg);
-
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
[RFC: 2.6 patch] make __put_super() static
This patch makes the needlessly global __put_super() static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
fs/super.c |2 +-
include/linux/fs.h |1 -
2 files changed, 1 insertion(+), 2 deletions(-)
2f076cdd5f1d693cc46559d48df6b060242e7f4c diff --git a/fs/super.c b/fs/super.c
index 88811f6..260f4f4 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -115,7 +115,7 @@ static inline void destroy_super(struct super_block *s)
* Drop a superblock's refcount. Returns non-zero if the superblock was
* destroyed. The caller must hold sb_lock.
*/
-int __put_super(struct super_block *sb)
+static int __put_super(struct super_block *sb)
{
int ret = 0;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 23528b8..f16e8fc 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1471,7 +1471,6 @@ extern int get_sb_pseudo(struct file_system_type *, char
*,
const struct super_operations *ops, unsigned long,
struct vfsmount *mnt);
extern int simple_set_mnt(struct vfsmount *mnt, struct super_block *sb);
-int __put_super(struct super_block *sb);
int __put_super_and_need_restart(struct super_block *sb);
void unnamed_dev_init(void);
-
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
Question regarding get_block() functions of filesystems.
Hi,
I can see at lot of places in the kernel code, sector_t and long have
been used interchangeably. Since sector_t is defined as u64 or
unsigned long
it will be issue for large file block numbers.
Searching google I found that there have been discussions regarding
this and some patch submitted too for some modules (links below), but
the current latest stable kernel
still seems to have this. As there appears to be printing issues with
using sector_t can anyone tell whether we need the cleanup in existing
Filesystem code or not ?
Previous patches :
1) http://lwn.net/Articles/8437/
2) http://osdir.com/ml/file-systems.ext2.devel/2006-05/msg00037.html
Below are some of the codes where they are used.
547 int ext2_get_block(struct inode *inode, sector_t iblock, struct
buffer_head *bh_result, int create)
548 {
549 int err = -EIO;
550 int offsets[4];
551 Indirect chain[4];
552 Indirect *partial;
553 unsigned long goal;
554 int left;
555 int boundary = 0;
556 int depth = ext2_block_to_path(inode, iblock, offsets, boundary);
..
...
196 static int ext2_block_to_path(struct inode *inode,
197long i_block, int offsets[4], int *boundary)
198 {
.
.
52 int V1_minix_get_block(struct inode * inode, long block,
53struct buffer_head *bh_result, int create)
54 {
.
.
--
Thanks a lot in advance.
Thanks Regards,
Manish Katiyar ( http://mkatiyar.googlepages.com )
3rd Floor, Fair Winds Block
EGL Software Park
Off Intermediate Ring Road
Bangalore 560071, India
***
-
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: [2.6 patch] make vfs_ioctl() static
On Sun, Feb 17, 2008 at 10:18:42AM +0200, Adrian Bunk wrote: This patch makes the needlessly global vfs_ioctl() static. I think the point was toa eventually export it for stackable filesystem use. But until they start using it marking it static seems fine with me. - 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 0/8][for -mm] mem_notify v6
I just noticed this patchset, kosaki-san. It looks quite interesting;
my apologies for not commenting earlier.
I see mention somewhere that mem_notify is of particular interest to
embedded systems.
I have what seems, intuitively, a similar problem at the opposite
end of the world, on big-honkin NUMA boxes (hundreds or thousands of
CPUs, terabytes of main memory.) The problem there is often best
resolved if we can kill the offending task, rather than shrink its
memory footprint. The situation is that several compute intensive
multi-threaded jobs are running, each in their own dedicated cpuset.
If one of these jobs tries to use more memory than is available in
its cpuset, then
(1) we quickly loose any hope of that job continuing at the excellent
performance needed of it, and
(2) we rapidly get increased risk of that job starting to swap and
unintentionally impact shared resources (kernel locks, disk
channels, disk heads).
So we like to identify such jobs as soon as they begin to swap,
and kill them very very quickly (before the direct reclaim code
in mm/vmscan.c can push more than a few pages to the swap device.)
For a much earlier, unsuccessful, attempt to accomplish this, see:
[Patch] cpusets policy kill no swap
http://lkml.org/lkml/2005/3/19/148
Now, it may well be that we are too far apart to share any part of
a solution; one seldom uses the same technology to build a Tour de
France bicycle as one uses to build a Lockheed C-5A Galaxy heavy
cargo transport.
One clear difference is the policy of what action we desire to take
when under memory pressure: do we invite user space to free memory so
as to avoid the wrath of the oom killer, or do we go to the opposite
extreme, seeking a nearly instantant killing, faster than the oom
killer can even begin its search for a victim.
Another clear difference is the use of cpusets, which are a major and
vital part of administering the big NUMA boxes, and I presume are not
even compiled into embedded kernels (correct?). This difference maybe
unbridgeable ... these big NUMA systems require per-cpuset mechanisms,
whereas embedded may require builds without cpusets.
However ... there might be some useful cross pollination of ideas.
I see in the latest posts to your mem_notify patchset v6, responding
to comments by Andrew and Andi on Feb 12 and 13, that you decided to
think more about the design of this, so perhaps this is a good time
for some random ideas from myself, even though I'm clearly coming from
a quite different problem space in some ways.
1) You have a little bit of code in the kernel to throttle the
thundering herd problem. Perhaps this could be moved to user space
... one user daemon that is always notified of such memory pressure
alarms, and in turn notifies interested applications. This might
avoid the need to add poll_wait_exclusive() to the kernel. And it
moves any fussy details of how to tame the thundering herd out of
the kernel.
2) Another possible mechanism for communicating events from
the kernel to user space is inotify. For example, I added
the line:
fsnotify_modify(dentry); # dentry is current tasks cpuset
at an interesting spot in vmscan.c, and using inotify-tools
inotify-tools.sourceforge.net/ could easily watch all cpusets
for these events from one user space daemon.
At this point, I have no idea whether this odd use of inotify
is better or worse than what your patchset has. However using
inotify did require less new kernel code, and with such user space
mechanisms as inotify-tools already well developed, it made the
problem I had, of watching an entire hierarcy of special files
(beneath /dev/cpuset) very easy to implement. At least inotify
also presents events on a file descriptor that can be consumed
using a poll() loop.
3) Perhaps, instead of sending simple events, one could update
a meter of the rate of recent such events, such as the per-cpuset
'memory_pressure' mechanism does. This might lead to addressing
Andrew Morton's comment:
If this feature is useful then I'd expect that some
applications would want notification at different times, or at
different levels of VM distress. So this semi-randomly-chosen
notification point just won't be strong enough in real-world
use.
4) A place that I found well suited for my purposes (watching for
swapping from direct reclaim) was just before the lines in the
pageout() routine in mm/vmscan.c:
if (clear_page_dirty_for_io(page)) {
...
res = mapping-a_ops-writepage(page, wbc);
It seemed that testing PageAnon(page) here allowed me to easily
distinguish between dirty pages going back to the file system, and
pages going to swap (this detail is from work on a 2.6.16 kernel;
things might have changed.)
One possible advantage of the above hook in the direct reclaim
Re: [RFC] Add vfsmount to vfs helper functions.
On Sun, Feb 17, 2008 at 06:00:30PM +0900, Tetsuo Handa wrote: Hello. This is (c) Add new hooks. approach I proposed at http://www.mail-archive.com/linux-fsdevel@vger.kernel.org/msg11536.html . Although this is an incomplete patch, I want to know whether you can tolerate this approach or not. If you cannot tolerate this approach, may be we need to consider implementing (d) Calculate pathname while doing name resolution approach. No printable comments, except for that: (e) why don't you guys move the Linus' Serious Mistake to _callers_ of vfs_mknod() and its ilk? Which obviously solves all problems with having vfsmount. - 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] Add vfsmount to vfs helper functions.
Hello. No printable comments, except for that: (e) why don't you guys move the Linus' Serious Mistake to _callers_ of vfs_mknod() and its ilk? Which obviously solves all problems with having vfsmount. Excuse me. I didn't understand what the Linus' Serious Mistake to _callers_ of vfs_mknod() is. Could you give me some URLs or hints? Regards. - 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
