--AhhlLboLdkugWU4S
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sun, Nov 13, 2005 at 11:44:38PM +0000, Michael van Elst wrote:
> >On Sun, Nov 13, 2005 at 09:45:14PM +0100, Michael van Elst wrote:
> >> When d_off is not a valid offset, the llseek fails and the next
> >> iteration may or may not read more directory entries.
> 
> >How can d_off be invalid? It was returned by the kernel before, so it
> >should be valid, no?
> 
> With tmpfs (and NFS) d_off is an opaque cookie and does
> not resemble an offset into the "directory file".

Ditto for udf... it does resemble an offset in the `directory file' only 
that directory file is NOT composed of dirents. So the normal directory ops 
work (i.e. reading from a previously returned place) but lseek() will fail.

Similar things are currenly also happening with the 
compat/common/vfs_syscalls_30.c : compat_30_sys_getdents() function on a 
UDF mount.

The compat code ignores the offset returned in the uio as a new starting 
point but starts calculating its own offset based on the sizes of the 
dirents and a new call thus fails since UDF doesn't return NFS cookies yet. 
Its harmless for its only gets called in this way at the end of the stream 
but still it might alarm users.

Regards,
Reinoud


--AhhlLboLdkugWU4S
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQ+Nk04KcNwBDyKpoAQL7EwgAuS5qbtCN2ukozTPRzn4Fg9zNMJ18bxNf
lTvf3y4KCLAZTmJUDpgv68ptDM29Bk0odlledIKIfGBk5tDtRwLGhowEYYK/fALz
NAmbjBXJIbuHXHrxM/hip/oEewrRJJbV6bIqE7iBrzvJlsaz7LbGtUgtADqFiJVF
x+VBvPWdlv/mbAiXOnoPE+evsTQL1fOfOTxCs+09j8o3+pO0Y9Uhwz52WfuTyiTe
EymVBPImsdR6UvC0hjMoVCeamghhttAIZ4RRjC0CVOHtxwG7R3pxEuK8diOxlo8Q
7vnh+B66WQdRAR4VBg0LJUXmyyk9jxUq2Q8exDLmCRNZOyhfxMox1A==
=sEod
-----END PGP SIGNATURE-----

--AhhlLboLdkugWU4S--