Hi Linus,
On Fri, 19 Aug 2005, 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 original patch had
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 fin
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 doesn't need any fixing
any more.
It was makign an assumption that used
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, smb
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. T
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" point
On Fri, Aug 19, 2005 at 01:35:49PM -0700, Linus Torvalds wrote:
> I'm not sure if this merits a new file or new organization (hey,
> fs/lib/xxx might be good in theory). In particular, I had actually been
> hoping to release 2.6.13 today, but this seems like a valid thing to hold
> things up for -
On Fri, 19 Aug 2005, Linus Torvalds wrote:
> 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 whet
On Fri, 19 Aug 2005, Anton Altaparmakov wrote:
>
> You are throwing away the error return from vfs_readlink(). I suspect you
> wanted:
>
> + cookie = ERR_PTR(res);
Yes, thanks.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
th
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
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
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 wo
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).
>
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 tog
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 wi
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...
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the b
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. The
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 with a symlink?
The forme
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 d
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 - completely
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 event
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]
* stray_pa
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
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
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 [..]
Looki
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
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 ev
On Fri, Aug 19, 2005 at 04:44:06PM +0100, Anton Altaparmakov wrote:
> I tried stracing nautilus to answer your question. And this time for
> the first time instead of a Bad page state I got a BUG() triggered in
> fs/namei.c, the arrow below marks the spot:
>
> void page_put_link(struct dentry *de
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
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"
> retur
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 kernels
31 matches
Mail list logo
