Hi,
I have a piece of code in my 2.6 kernel that associates an ioctl
file_operation to nfs in file.c and dir.c.
This ioctl sends the nfs_fh to a userland application.
I have been trying to remove this ugly code by creating my own device
and implementing the ioctl but I keep getting junk instead.
Please tell me if I'm doing anything wrong here:
1) Define the I/O structure:
struct nfs_getfh {
int fd;
struct nfs_fh *fh;
};
2) Receive the fd of the wanted file/dir.
3) inside the ioctl function:
struct file *filp;
struct dentry *dentp;
struct inode *inop;
struct nfs_getfh getfh;
struct files_struct *files;
struct nfs_getfh __user *user_getfh = (struct nfs_getfh __user *)
arg;
files = current->files;
if (files) {
spin_lock(&files->file_lock);
filp = fcheck(getfh.fd);
if (filp) {
dentp = dget(filp->f_dentry);
if (dentp) {
inop = dentp->d_inode;
if (inop) {
getfh.fh = NFS_FH(inop);
if (getfh.fh) {
copy_to_user((void*) user_getfh->fh, getfh.fh,
getfh.fh->size + ((int) &((struct nfs_fh*)0)->data)))
}
}
}
}
spin_unlock(&files->file_lock);
}
Best Regards,
Menny
On Thu, Feb 08, 2007 at 06:38:48PM +0200, Menny Hamburger wrote:
> I have a piece of code in my 2.6 kernel that associates an ioctl
> file_operation to nfs in file.c and dir.c.
> This ioctl sends the nfs_fh to a userland application.
Doesn't /proc/fs/nfsd/filehandle do what you want already?
See nfs-util/utils/mountd/cache.c:cache_get_filehandle(), or, for the
kernel side, linux/fs/nfsd/nfsctl.c:write_filehandle().
(Just out of curiosity--why are you doing this?)
--b.
We implement our own nfsd in user space - so the kernel nfsd (as well
as the lockd) are disabled.
We need the handle in order to associate a kernel file handle with our
own file id.
M.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of J. Bruce Fields
Sent: Thursday, February 08, 2007 10:12 PM
To: Menny Hamburger
Cc: [email protected]
Subject: Re: Getting the nfs_fh of a specific file/dir from the kernel
On Thu, Feb 08, 2007 at 06:38:48PM +0200, Menny Hamburger wrote:
> I have a piece of code in my 2.6 kernel that associates an ioctl
> file_operation to nfs in file.c and dir.c.
> This ioctl sends the nfs_fh to a userland application.
Doesn't /proc/fs/nfsd/filehandle do what you want already?
See nfs-util/utils/mountd/cache.c:cache_get_filehandle(), or, for the
kernel side, linux/fs/nfsd/nfsctl.c:write_filehandle().
(Just out of curiosity--why are you doing this?)
--b.
On Sun, 2007-02-11 at 10:06 +0200, Menny Hamburger wrote:
> We implement our own nfsd in user space - so the kernel nfsd (as well
> as the lockd) are disabled.
> We need the handle in order to associate a kernel file handle with our
> own file id.
Filehandles are not part of any API that is exported to userland. There
are many reasons why that would be a bad idea.
Cheers
Trond
> M.
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of J. Bruce Fields
> Sent: Thursday, February 08, 2007 10:12 PM
> To: Menny Hamburger
> Cc: [email protected]
> Subject: Re: Getting the nfs_fh of a specific file/dir from the kernel
>
> On Thu, Feb 08, 2007 at 06:38:48PM +0200, Menny Hamburger wrote:
> > I have a piece of code in my 2.6 kernel that associates an ioctl
> > file_operation to nfs in file.c and dir.c.
> > This ioctl sends the nfs_fh to a userland application.
>
> Doesn't /proc/fs/nfsd/filehandle do what you want already?
>
> See nfs-util/utils/mountd/cache.c:cache_get_filehandle(), or, for the
> kernel side, linux/fs/nfsd/nfsctl.c:write_filehandle().
>
> (Just out of curiosity--why are you doing this?)
>
> --b.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to [email protected] More majordomo
> info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Tue, Feb 13, 2007 at 03:13:01PM -0800, Trond Myklebust wrote:
> On Sun, 2007-02-11 at 10:06 +0200, Menny Hamburger wrote:
> > We implement our own nfsd in user space - so the kernel nfsd (as well
> > as the lockd) are disabled.
> > We need the handle in order to associate a kernel file handle with our
> > own file id.
>
> Filehandles are not part of any API that is exported to userland.
/proc/fs/nfsd/filehandle ???
--b.
On Tue, 2007-02-13 at 18:16 -0500, J. Bruce Fields wrote:
> On Tue, Feb 13, 2007 at 03:13:01PM -0800, Trond Myklebust wrote:
> > On Sun, 2007-02-11 at 10:06 +0200, Menny Hamburger wrote:
> > > We implement our own nfsd in user space - so the kernel nfsd (as well
> > > as the lockd) are disabled.
> > > We need the handle in order to associate a kernel file handle with our
> > > own file id.
> >
> > Filehandles are not part of any API that is exported to userland.
>
> /proc/fs/nfsd/filehandle ???
That is only the information needed by mountd. It should not be usable
for opening random files etc.
Cheers
Trond
On Tue, Feb 13, 2007 at 03:19:40PM -0800, Trond Myklebust wrote:
> On Tue, 2007-02-13 at 18:16 -0500, J. Bruce Fields wrote:
> > On Tue, Feb 13, 2007 at 03:13:01PM -0800, Trond Myklebust wrote:
> > > On Sun, 2007-02-11 at 10:06 +0200, Menny Hamburger wrote:
> > > > We implement our own nfsd in user space - so the kernel nfsd (as well
> > > > as the lockd) are disabled.
> > > > We need the handle in order to associate a kernel file handle with our
> > > > own file id.
> > >
> > > Filehandles are not part of any API that is exported to userland.
> >
> > /proc/fs/nfsd/filehandle ???
>
> That is only the information needed by mountd. It should not be usable
> for opening random files etc.
Oh, right--I guess it only gives filehandles for export roots--I'd
missed that.
--b.