Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Anton Altaparmakov
Hi, There is a bug somewhere in 2.6.11.4 and I can't figure out where it is. I assume it is present in older and newer kernels, too as the related code hasn't changed much AFAICS and googling for Bad page state returns rather a lot of hits relating to both older (up to 2.5.70!) and newer

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Al Viro
On Fri, Aug 19, 2005 at 12:14:48PM +0100, Anton Altaparmakov wrote: Hi, There is a bug somewhere in 2.6.11.4 and I can't figure out where it is. I assume it is present in older and newer kernels, too as the related code hasn't changed much AFAICS and googling for Bad page state returns

Re: Mirror a file system on the fly

2005-08-19 Thread Dave Schwartz
Ram, Your code snippet seems to work great as discussed. Thanks. :-) However, my requirement is slightly different. What I also want is that any file created from the mirrored/cloned file-system must not be available in the parent file system. Gracias, decebel On 8/18/05, Ram Pai [EMAIL

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Anton Altaparmakov
On Fri, 2005-08-19 at 15:20 +0100, Al Viro wrote: On Fri, Aug 19, 2005 at 12:14:48PM +0100, Anton Altaparmakov wrote: There is a bug somewhere in 2.6.11.4 and I can't figure out where it is. I assume it is present in older and newer kernels, too as the related code hasn't changed much

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Linus Torvalds
On Fri, 19 Aug 2005, Anton Altaparmakov wrote: struct page *page; page = find_get_page(dentry-d_inode-i_mapping, 0); if (!page) BUG(); Something has truncated the mapping. My guess is that you had a cache invalidate event

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Al Viro
On Fri, Aug 19, 2005 at 09:07:35AM -0700, Linus Torvalds wrote: Hmm.. NFS _does_ use the page cache for symlinks, but uses it slightly differently: instead of relying on the page cache entry being the same when freeing the page, it just caches the page it looked up in the page cache (ie

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Linus Torvalds
On Fri, 19 Aug 2005, Linus Torvalds wrote: The generic page cache for symlinks code does _not_ support invalidating the cache while it's being used. A local filesystem will obviously never invalidate the cache at all. Hmm.. NFS _does_ use the page cache for symlinks [..] Looking more

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Linus Torvalds
On Fri, 19 Aug 2005, Linus Torvalds wrote: - document this as a fundamental fact, and apply the ncpfs patch. Local filesystems can still continue to use the generic helper functions (all other users _are_ local filesystems). Actually, looking at the ncpfs patch, I'd rather not

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Al Viro
On Fri, Aug 19, 2005 at 09:43:17AM -0700, Linus Torvalds wrote: Actually, looking at the ncpfs patch, I'd rather not apply that patch as-is. It looks like it will totally disable symlink caching, which would be kind of sad. Somebody willing to do the same thing NFS does? NFS hides away the

[RFC][PATCH] Generic fallback for security xattrs

2005-08-19 Thread Stephen Smalley
This is a request for comments (only) on the patch below that modifies the VFS setxattr, getxattr, and listxattr code to fall back to the security module for security xattrs if the filesystem does not support xattrs natively. This allows security modules to export the incore inode security label

Re: [RFC][PATCH] Generic fallback for security xattrs

2005-08-19 Thread Christoph Hellwig
On Fri, Aug 19, 2005 at 01:57:56PM -0400, Stephen Smalley wrote: This is a request for comments (only) on the patch below that modifies the VFS setxattr, getxattr, and listxattr code to fall back to the security module for security xattrs if the filesystem does not support xattrs natively.

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Al Viro
On Fri, Aug 19, 2005 at 05:53:32PM +0100, Al Viro wrote: I'm taking NFS helpers to libfs.c and switching ncpfs to them. IMO that's better than copying the damn thing and other network filesystems might have the same needs eventually... [something like this - completely untested] *

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Christoph Hellwig
On Fri, Aug 19, 2005 at 07:02:18PM +0100, Al Viro wrote: On Fri, Aug 19, 2005 at 05:53:32PM +0100, Al Viro wrote: I'm taking NFS helpers to libfs.c and switching ncpfs to them. IMO that's better than copying the damn thing and other network filesystems might have the same needs

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Mika Penttilä
Al Viro wrote: On Fri, Aug 19, 2005 at 05:53:32PM +0100, Al Viro wrote: I'm taking NFS helpers to libfs.c and switching ncpfs to them. IMO that's better than copying the damn thing and other network filesystems might have the same needs eventually... [something like this -

[RFC] [PATCH] Stacking support for inode_init_security

2005-08-19 Thread hallyn
The following patch changes the (new to -mm) inode_init_security function to support multiple LSMs. It does this by placing the three passed arguments (name, value, len) into a structure, and passing in a list_head, onto which the structure can be appended. The callers (filesystems) call their

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Al Viro
On Fri, Aug 19, 2005 at 07:00:38PM +0100, Christoph Hellwig wrote: On Fri, Aug 19, 2005 at 07:02:18PM +0100, Al Viro wrote: On Fri, Aug 19, 2005 at 05:53:32PM +0100, Al Viro wrote: I'm taking NFS helpers to libfs.c and switching ncpfs to them. IMO that's better than copying the damn

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Matthew Wilcox
On Fri, Aug 19, 2005 at 08:38:34PM +0100, Al Viro wrote: FWIW, I'd rather take page_symlink(), page_symlink_inode_operations, page_put_link(), page_follow_link_light(), page_readlink(), page_getlink(), generic_readlink() and vfs_readlink() to the same place where these guys would live. They

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Mika Penttilä
Al Viro wrote: On Fri, Aug 19, 2005 at 10:16:47PM +0300, Mika Penttilä wrote: Just out of curiosity - what protects even local filesystems against concurrent truncate and symlink resolving when using the page cache helpers? How do you get truncate(2) or ftruncate(2) to do something

[PATCH] fix cramfs making duplicate entries in inode cache

2005-08-19 Thread Dave Johnson
Every time cramfs_lookup() is called to lookup and inode for a dentry, get_cramfs_inode() will allocate a new inode without checking to see if that inode already exists in the inode cache. This is fine the first time, but if the dentry cache entry(ies) associated with that inode are aged out,

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Linus Torvalds
On Fri, 19 Aug 2005, Al Viro wrote: FWIW, I'd rather take page_symlink(), page_symlink_inode_operations, page_put_link(), page_follow_link_light(), page_readlink(), page_getlink(), generic_readlink() and vfs_readlink() to the same place where these guys would live. They all belong

Re: [RFC][PATCH] Generic fallback for security xattrs

2005-08-19 Thread Jeff Mahoney
Christoph Hellwig wrote: Very nice, and gets rid of lots of crap. Now that we started parsing the attribute name in generic code we should deprecate the old -{get,set,list,remove}xattr inode operations and make the helpers James added a while ago mandatory for the future. I'd be fine with

Re: [RFC][PATCH] Generic fallback for security xattrs

2005-08-19 Thread Chris Wright
* Christoph Hellwig ([EMAIL PROTECTED]) wrote: On Fri, Aug 19, 2005 at 01:57:56PM -0400, Stephen Smalley wrote: Note that this approach may be controversial [1]; it has been suggested that we should instead be modifying all filesystem types to support security (and other) xattrs natively,

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Anton Altaparmakov
On Fri, 19 Aug 2005, Linus Torvalds wrote: On Fri, 19 Aug 2005, Linus Torvalds wrote: - document this as a fundamental fact, and apply the ncpfs patch. Local filesystems can still continue to use the generic helper functions (all other users _are_ local filesystems).

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Linus Torvalds
On Fri, 19 Aug 2005, Anton Altaparmakov wrote: It does disable link caching. But I didn't make this up. This is exactly what smbfs uses. I just copied smbfs given ncpfs copies almost everything smbfs does anyway... Can you test whether the untested test-patch I sent out seems to work

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Christoph Hellwig
On Fri, Aug 19, 2005 at 08:43:06PM +0100, Al Viro wrote: On Fri, Aug 19, 2005 at 08:41:29PM +0100, Matthew Wilcox wrote: is getting crowded. Linus, do you have any objections to that or suggestions on filename here? fs/symlink.c? Or fs/lib/symlink.c... That's a very good idea.

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Anton Altaparmakov
On Fri, 19 Aug 2005, Linus Torvalds wrote: The one thing that strikes me is that we might actually have less pain if we just changed the calling convention for follow_link/put_link slightly instead of creating a new library function. The existing page cache thing really _does_ work very

Re: [PATCH] fix cramfs making duplicate entries in inode cache

2005-08-19 Thread Phillip Lougher
Dave Johnson wrote: Patch below fixes this by making get_cramfs_inode() use the inode cache before blindly creating a new entry every time. This eliminates the duplicate inodes and duplicate buffer cache. + struct inode * inode = iget_locked(sb, CRAMINO(cramfs_inode)); Doesn't

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Linus Torvalds
On Fri, 19 Aug 2005, Anton Altaparmakov wrote: Yes, sure. I have applied your patch to our 2.6.11.4 tree (with the one liner change I emailed you just now) and have kicked off a compile. Actually, hold on. The original patch had another problem: it returned an uninitialized page pointer

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Al Viro
On Fri, Aug 19, 2005 at 03:04:52PM -0700, Linus Torvalds wrote: On Fri, 19 Aug 2005, Anton Altaparmakov wrote: Yes, sure. I have applied your patch to our 2.6.11.4 tree (with the one liner change I emailed you just now) and have kicked off a compile. Actually, hold on. The

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Al Viro
On Sat, Aug 20, 2005 at 12:15:42AM +0100, Al Viro wrote: That looks OK except for * jffs2 is b0rken (see patch in another mail) * afs, autofs4, befs, devfs, freevxfs, jffs2, jfs, ncpfs, procfs, smbfs, sysvfs, ufs, xfs - prototype change for -follow_link() * befs, smbfs,

Re: [PATCH] fix cramfs making duplicate entries in inode cache

2005-08-19 Thread Dave Johnson
Phillip Lougher writes: Doesn't iget_locked() assume inode numbers are unique? In Cramfs inode numbers are set to 1 for non-data inodes (fifos, sockets, devices, empty directories), i.e %stat device namedpipe File: `device' Size: 0 Blocks: 0 IO Block: 4096

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

2005-08-19 Thread Al Viro
On Fri, Aug 19, 2005 at 06:08:12PM -0700, Linus Torvalds wrote: On Sat, 20 Aug 2005, Al Viro wrote: That looks OK except for * ncpfs fix is actually missing here Well, the thing is, with the change to page_follow_link() and page_put_link(), ncpfs should now work fine - it

Re: [PATCH] fix cramfs making duplicate entries in inode cache

2005-08-19 Thread Dave Johnson
Dave Johnson writes: Phillip Lougher writes: Doesn't iget_locked() assume inode numbers are unique? In Cramfs inode numbers are set to 1 for non-data inodes (fifos, sockets, devices, empty directories), i.e %stat device namedpipe File: `device' Size: 0

Re: Mirror a file system on the fly

2005-08-19 Thread Dave Quigley
Dave Schwartz wrote: Ram, Your code snippet seems to work great as discussed. Thanks. :-) However, my requirement is slightly different. What I also want is that any file created from the mirrored/cloned file-system must not be available in the parent file system. Gracias, decebel On