Date: Sun, 30 Dec 2001 12:19:51 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Sheldon Hearn <sheldonh@starjuice.net> Cc: Michal Mertl <mime@traveller.cz>, current@FreeBSD.ORG, bmilekic@FreeBSD.ORG Subject: Re: ntfs and sendfile problem (corrupted data) Message-ID: <200112302019.fBUKJpZ16855@apollo.backplane.com> References: <91552.1009724501@axl.seasidesoftware.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Well, we have a problem here. smbfs is allowing VOBJBUF to be set
on its vnodes. This creates a backing VM object that smbfs never
uses and makes sendfile() believe that it can do UIO_NOCOPY uio's on
smbfs vnodes.
Michal, please try the following kernel patch and test it with the
normal ftpd (that tries to use sendfile()). Also test it with any
other programs you run on smbfs mounts. With this patch sendfile()
should now recognize that the filesystem does not support VMIO and
return an error, causing ftpd to use the old method automatically.
Unfortunately this patch creates another problem. smbfs() partially
worked with mmap() due to creating the backing object, and the
default pager ops can even read smbfs data into the backing object.
But data dirtied by the mmap() will likely not get written out and
there is no coherency between read() and mmap(). In otherwords, it
only 'kinda' supports mmap().
I believe the correct solution is to not support mmap() at all (or,
alternatively, correctly support mmap() which would be a lot of
work considering how minimal smbfs is).
Another possible solution would be to change sendfile() to attempt
to do a VOP_BMAP() or something like that, to determine whether
UIO_NOCOPY read operations are legal or not. Or we could introduce
a new VOP call to return whether it is legal to do a UIO_NOCOPY
read operation on the VM object's backing store.
-Matt
Matthew Dillon
<dillon@backplane.com>
:
:On Sun, 30 Dec 2001 15:47:45 +0100, Michal Mertl wrote:
:
:> I did use the "goto oldway;" and the problem went away. I tried to look at
:> /sys/kern/uipc_syscalls.c sendfile implementation but it is too complex
:> for me :-(.
:..
Index: fs/smbfs/smbfs_vnops.c
===================================================================
RCS file: /home/ncvs/src/sys/fs/smbfs/smbfs_vnops.c,v
retrieving revision 1.2.2.4
diff -u -r1.2.2.4 smbfs_vnops.c
--- fs/smbfs/smbfs_vnops.c 20 Dec 2001 16:11:49 -0000 1.2.2.4
+++ fs/smbfs/smbfs_vnops.c 30 Dec 2001 20:01:43 -0000
@@ -84,6 +84,7 @@
static int smbfs_pathconf(struct vop_pathconf_args *ap);
static int smbfs_advlock(struct vop_advlock_args *);
static int smbfs_getextattr(struct vop_getextattr_args *ap);
+static int smbfs_createvobject(struct vop_createvobject_args *ap);
vop_t **smbfs_vnodeop_p;
static struct vnodeopv_entry_desc smbfs_vnodeop_entries[] = {
@@ -92,6 +93,7 @@
{ &vop_advlock_desc, (vop_t *) smbfs_advlock },
{ &vop_bmap_desc, (vop_t *) smbfs_bmap },
{ &vop_close_desc, (vop_t *) smbfs_close },
+ { &vop_createvobject_desc, (vop_t *) smbfs_createvobject },
{ &vop_create_desc, (vop_t *) smbfs_create },
{ &vop_fsync_desc, (vop_t *) smbfs_fsync },
{ &vop_getattr_desc, (vop_t *) smbfs_getattr },
@@ -1331,3 +1333,15 @@
}
return 0;
}
+
+static int
+smbfs_createvobject(ap)
+ struct vop_createvobject_args /* {
+ struct vnode *vp;
+ struct ucred *cred;
+ struct proc *p;
+ } */ *ap;
+{
+ return(0);
+}
+
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112302019.fBUKJpZ16855>