This is a nontrivial change to the NFS client.
Synchronous READ operations are currently done via the ->read() nfs_rpc_op.
Therefore, the synchronous READ path can easily be adapted for NFSv4. On
the other hand, the asynchronous READ path contains several NFSv3-specific
features, which make it difficult to adapt for NFSv4.
In this patch and the next, we modify the async READ path to be
version-agnostic. This patch just changes the 'struct nfs_read_data'
so that the v2- and v3-specific parts are moved into a private area,
with room for a v4-specific part in parallel. None of the logic is
changed.
--- old/fs/nfs/read.c Wed Jul 24 16:03:17 2002
+++ new/fs/nfs/read.c Sat Aug 10 22:20:39 2002
@@ -38,11 +38,18 @@ struct nfs_read_data {
struct rpc_task task;
struct inode *inode;
struct rpc_cred *cred;
- struct nfs_readargs args; /* XDR argument struct */
- struct nfs_readres res; /* ... and result struct */
struct nfs_fattr fattr; /* fattr storage */
struct list_head pages; /* Coalesced read requests */
struct page *pagevec[NFS_READ_MAXIOV];
+ union {
+ struct {
+ struct nfs_readargs args;
+ struct nfs_readres res;
+ } v3; /* also v2 */
+#ifdef CONFIG_NFS_V4
+ /* NFSv4 data will come here... */
+#endif
+ } u;
};
/*
@@ -64,7 +71,6 @@ static __inline__ struct nfs_read_data *
if (p) {
memset(p, 0, sizeof(*p));
INIT_LIST_HEAD(&p->pages);
- p->args.pages = p->pagevec;
}
return p;
}
@@ -194,7 +200,7 @@ nfs_read_rpcsetup(struct list_head *head
struct page **pages;
unsigned int count;
- pages = data->args.pages;
+ pages = data->pagevec;
count = 0;
while (!list_empty(head)) {
struct nfs_page *req = nfs_list_entry(head->next);
@@ -206,13 +212,14 @@ nfs_read_rpcsetup(struct list_head *head
req = nfs_list_entry(data->pages.next);
data->inode = req->wb_inode;
data->cred = req->wb_cred;
- data->args.fh = NFS_FH(req->wb_inode);
- data->args.offset = page_offset(req->wb_page) + req->wb_offset;
- data->args.pgbase = req->wb_offset;
- data->args.count = count;
- data->res.fattr = &data->fattr;
- data->res.count = count;
- data->res.eof = 0;
+ data->u.v3.args.fh = NFS_FH(req->wb_inode);
+ data->u.v3.args.offset = page_offset(req->wb_page) + req->wb_offset;
+ data->u.v3.args.pgbase = req->wb_offset;
+ data->u.v3.args.pages = pages;
+ data->u.v3.args.count = count;
+ data->u.v3.res.fattr = &data->fattr;
+ data->u.v3.res.count = count;
+ data->u.v3.res.eof = 0;
}
static void
@@ -264,8 +271,8 @@ nfs_pagein_one(struct list_head *head, s
#else
msg.rpc_proc = NFSPROC_READ;
#endif
- msg.rpc_argp = &data->args;
- msg.rpc_resp = &data->res;
+ msg.rpc_argp = &data->u.v3.args;
+ msg.rpc_resp = &data->u.v3.res;
msg.rpc_cred = data->cred;
/* Start the async call */
@@ -273,8 +280,8 @@ nfs_pagein_one(struct list_head *head, s
task->tk_pid,
inode->i_sb->s_id,
(long long)NFS_FILEID(inode),
- (unsigned int)data->args.count,
- (unsigned long long)data->args.offset);
+ (unsigned int)data->u.v3.args.count,
+ (unsigned long long)data->u.v3.args.offset);
rpc_clnt_sigmask(clnt, &oldset);
rpc_call_setup(task, &msg, 0);
@@ -404,7 +411,7 @@ nfs_readpage_result(struct rpc_task *tas
{
struct nfs_read_data *data = (struct nfs_read_data *) task->tk_calldata;
struct inode *inode = data->inode;
- unsigned int count = data->res.count;
+ unsigned int count = data->u.v3.res.count;
dprintk("NFS: %4d nfs_readpage_result, (status %d)\n",
task->tk_pid, task->tk_status);
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Dax Kelson <[email protected]> writes:
> I for one would REALLY like to see NFSv4 (actually, Kerberized
> NFSv4 is what I'm after). I just finished setting up a
> Kerberized Solaris NFS environment with home directories
> automounted from the clients with strong user authentication.
> Frankly, the stock (non-Kerberized) NFS security model blows.
Note: The RPCSEC_GSS (and accompanying kerberos) stuff is completely
independent of NFSv4. It is still in the process of being finalized,
but when it is, it will apply to NFSv2/v3 as well as v4.
RPCSEC_GSS is not an argument for NFSv4...
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, 14 Aug 2002, Brian Pawlowski wrote:
> > RPCSEC_GSS is not an argument for NFSv4...
>
> yes.
>
> But ACL support over the wire is an argument for V4 - and fine grained
> authorization coupled to strong authentication makes for a flexible
> security package.
Not really. With the quality of existing userland (Linux, Solaris, *BSD,
NT, etc.) _anything_ more complex than "I'm the only one who can create
or remove objects here" is a big, gaping hole. Which makes any theoretical
benefits (if any) of ACL-based schemes moot. Same (to slightly less extent)
applies to regular files.
In other words, if you need something more complex than usual - you are
screwed on the userland side, regardless of the kernel behaviour.
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, 2002-08-14 at 21:49, Dax Kelson wrote:
> The fact that any janitor with a laptop (or any client with a malicious
> root user) can nuke all home directories from a standard NFS home
> directory server bothers me greatly.
Thats not an NFS2 or NFS3 issue, thats an implementation matter. A
proper NFS credential system prevents that from occurring. You also have
to fix some bogon assumptions in our NFS client too I grant.
Alan (who is rapidly becoming an intermezzo freak instead)
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, 2002-08-14 at 23:34, Brian Pawlowski wrote:
> But ACL support over the wire is an argument for V4 - and fine grained
> authorization coupled to strong authentication makes for a flexible
> security package.
ACL works in NFSv2 and nicely in NFSv3 - again the problems Linux has
are the client failing to respect basic NFS rules of operation.
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Linus, I'm curious if the NFSv4 patches will be accepted in the near
future (ie, before 2.6).
I for one would REALLY like to see NFSv4 (actually, Kerberized NFSv4 is
what I'm after). I just finished setting up a Kerberized Solaris NFS
environment with home directories automounted from the clients with
strong user authentication.
Frankly, the stock (non-Kerberized) NFS security model blows.
The fact that any janitor with a laptop (or any client with a malicious
root user) can nuke all home directories from a standard NFS home
directory server bothers me greatly.
Dax Kelson
Guru Labs
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs