From: Pozsar Balazs <pozsy@uhulinux.hu>
To: linux-kernel@vger.kernel.org
Subject: Re: 2.4.23-pre8-pac1 and since: NFSv3 problem
Date: Thu, 4 Dec 2003 23:41:32 +0100 [thread overview]
Message-ID: <20031204224132.GA1906@unicorn.sch.bme.hu> (raw)
In-Reply-To: <20031129133252.GA2403@athame.dynamicro.on.ca>
Could someone please send a patch to fix this against 2.4.23-pac1?
Thanks in advance.
On Sat, Nov 29, 2003 at 08:32:52AM -0500, Greg Louis wrote:
> This is still present in kernel 2.4.23-pac1.
>
> On 20031115 (Sat) at 0055:23 +0100, J.A. Magallon wrote:
> >
> > On 11.15, J.A. Magallon wrote:
> > >
> > > On 11.11, Greg Louis wrote:
> > > > On 20031111 (Tue) at 1326:47 -0500, Greg Louis wrote:
> > > > > Kernels 2.4.23-pre7-pac1 and 2.4.23-rc1 are ok but -pre8-pac1 and
> > > > > -rc1-pac1 behave as follows: mounting a remote directory via NFS with
> > > > > v3 enabled (client and server) seems to work ok, and running mount with
> > > > > no parameters shows the NFS mount, but any attempt at access fails with
> > > > > a message like
> > > > > /bin/ls: reading directory /whatever/it/was: Input/output error
> > > >
> > > > Reverting all changes to fs/nfs/* since 2.4.23-pre7-pac1, and only
> > > > those, corrects the problem.
> > > >
> > >
> > > /metoo
> > >
> > > annwn:~> bpsh 0 mount
> > > none on /proc type proc (rw)
> > > none on /dev/pts type devpts (rw,mode=0620)
> > > none on /dev/shm type tmpfs (rw)
> > > none on /tmp type tmpfs (rw)
> > > 192.168.0.1:/lib on /lib type nfs (ro,noatime,nfsvers=3,nolock,addr=192.168.0.1)
> > > 192.168.0.1:/bin on /bin type nfs (ro,noatime,nfsvers=3,nolock,addr=192.168.0.1)
> > > 192.168.0.1:/sbin on /sbin type nfs (ro,noatime,nfsvers=3,nolock,addr=192.168.0.1)
> > > 192.168.0.1:/usr on /usr type nfs (ro,noatime,nfsvers=3,nolock,addr=192.168.0.1)
> > > 192.168.0.1:/opt on /opt type nfs (ro,noatime,nfsvers=3,nolock,addr=192.168.0.1)
> > > 192.168.0.1:/home on /home type nfs (rw,nfsvers=3,noac,addr=192.168.0.1)
> > > 192.168.0.1:/work on /work/shared type nfs (rw,nfsvers=3,noac,addr=192.168.0.1)
> > >
> > > annwn:~> bpsh 0 pwd
> > > /home/magallon
> > >
> > > annwn:~> bpsh 0 ls
> > > ls: reading directory .: Invalid argument
> > >
> > > It works for some time, and then it breaks.
> > > Could you send me the patch you used to revert those changes ?
> > > I will try to make a diff from rc1 to pre7 and reverse.
> >
> > Just this (pre7 -> pre8|rc1):
> >
> > diff -ruN linux-2.4.23-pre7/fs/nfs/nfs3proc.c linux-2.4.23-rc1/fs/nfs/nfs3proc.c
> > --- linux-2.4.23-pre7/fs/nfs/nfs3proc.c 2003-08-25 13:44:43.000000000 +0200
> > +++ linux-2.4.23-rc1/fs/nfs/nfs3proc.c 2003-11-12 11:07:48.000000000 +0100
> > @@ -433,8 +433,6 @@
> > * The decode function itself doesn't perform any decoding, it just makes
> > * sure the reply is syntactically correct.
> > *
> > - * Also note that this implementation handles both plain readdir and
> > - * readdirplus.
> > */
> > static int
> > nfs3_proc_readdir(struct inode *dir, struct rpc_cred *cred,
> > @@ -448,11 +446,7 @@
> > struct rpc_message msg = { NFS3PROC_READDIR, &arg, &res, cred };
> > int status;
> >
> > - if (plus)
> > - msg.rpc_proc = NFS3PROC_READDIRPLUS;
> > -
> > - dprintk("NFS call readdir%s %d\n",
> > - plus? "plus" : "", (unsigned int) cookie);
> > + dprintk("NFS call readdir %d\n", (unsigned int) cookie);
> >
> > dir_attr.valid = 0;
> > status = rpc_call_sync(NFS_CLIENT(dir), &msg, 0);
> > diff -ruN linux-2.4.23-pre7/fs/nfs/nfs3xdr.c linux-2.4.23-rc1/fs/nfs/nfs3xdr.c
> > --- linux-2.4.23-pre7/fs/nfs/nfs3xdr.c 2002-11-29 00:53:15.000000000 +0100
> > +++ linux-2.4.23-rc1/fs/nfs/nfs3xdr.c 2003-11-12 11:07:48.000000000 +0100
> > @@ -599,8 +599,6 @@
> > u32 *
> > nfs3_decode_dirent(u32 *p, struct nfs_entry *entry, int plus)
> > {
> > - struct nfs_entry old = *entry;
> > -
> > if (!*p++) {
> > if (!*p)
> > return ERR_PTR(-EAGAIN);
> > @@ -616,20 +614,12 @@
> > p = xdr_decode_hyper(p, &entry->cookie);
> >
> > if (plus) {
> > - p = xdr_decode_post_op_attr(p, &entry->fattr);
> > + struct nfs_fattr fattr;
> > + p = xdr_decode_post_op_attr(p, &fattr);
> > /* In fact, a post_op_fh3: */
> > if (*p++) {
> > - p = xdr_decode_fhandle(p, &entry->fh);
> > - /* Ugh -- server reply was truncated */
> > - if (p == NULL) {
> > - dprintk("NFS: FH truncated\n");
> > - *entry = old;
> > - return ERR_PTR(-EAGAIN);
> > - }
> > - } else {
> > - /* If we don't get a file handle, the attrs
> > - * aren't worth a lot. */
> > - entry->fattr.valid = 0;
> > + struct nfs_fh fh;
> > + p = xdr_decode_fhandle(p, &fh);
> > }
> > }
> >
> > diff -ruN linux-2.4.23-pre7/fs/nfs/write.c linux-2.4.23-rc1/fs/nfs/write.c
> > --- linux-2.4.23-pre7/fs/nfs/write.c 2003-08-25 13:44:43.000000000 +0200
> > +++ linux-2.4.23-rc1/fs/nfs/write.c 2003-11-12 11:07:48.000000000 +0100
> > @@ -225,8 +225,19 @@
> > struct inode *inode = page->mapping->host;
> > unsigned long end_index;
> > unsigned offset = PAGE_CACHE_SIZE;
> > + int inode_referenced = 0;
> > int err;
> >
> > + /*
> > + * Note: We need to ensure that we have a reference to the inode
> > + * if we are to do asynchronous writes. If not, waiting
> > + * in nfs_wait_on_request() may deadlock with clear_inode().
> > + *
> > + * If igrab() fails here, then it is in any case safe to
> > + * call nfs_wb_page(), since there will be no pending writes.
> > + */
> > + if (igrab(inode) != 0)
> > + inode_referenced = 1;
> > end_index = inode->i_size >> PAGE_CACHE_SHIFT;
> >
> > /* Ensure we've flushed out any previous writes */
> > @@ -244,7 +255,8 @@
> > goto out;
> > do_it:
> > lock_kernel();
> > - if (NFS_SERVER(inode)->wsize >= PAGE_CACHE_SIZE && !IS_SYNC(inode)) {
> > + if (NFS_SERVER(inode)->wsize >= PAGE_CACHE_SIZE && !IS_SYNC(inode) &&
> > + inode_referenced) {
> > err = nfs_writepage_async(NULL, inode, page, 0, offset);
> > if (err >= 0)
> > err = 0;
> > @@ -256,7 +268,9 @@
> > unlock_kernel();
> > out:
> > UnlockPage(page);
> > - return err;
> > + if (inode_referenced)
> > + iput(inode);
> > + return err;
> > }
> >
> > /*
> >
> > --
> > J.A. Magallon <jamagallon()able!es> \ Software is like sex:
> > werewolf!able!es \ It's better when it's free
> > Mandrake Linux release 10.0 (Cooker) for i586
> > Linux 2.4.23-rc1-jam1 (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-4mdk))
>
> --
> | G r e g L o u i s | gpg public key: 0x400B1AA86D9E3E64 |
> | http://www.bgl.nu/~glouis | (on my website or any keyserver) |
> | http://wecanstopspam.org in signatures helps fight junk email. |
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
--
pozsy
next prev parent reply other threads:[~2003-12-04 22:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-11 18:26 2.4.23-pre8-pac1 and -rc1-pac1 NFSv3 problem Greg Louis
2003-11-11 19:00 ` Greg Louis
2003-11-14 23:46 ` J.A. Magallon
2003-11-14 23:55 ` J.A. Magallon
2003-11-15 0:14 ` PowerBook shutdown Dustin Lang
2003-11-28 20:38 ` 2.4.23-pac1 Bernhard Rosenkraenzer
2003-11-29 13:32 ` 2.4.23-pre8-pac1 and since: NFSv3 problem Greg Louis
2003-12-04 22:41 ` Pozsar Balazs [this message]
2003-12-02 3:42 ` 2.4.23-pac1 VIA/S3 DRM compilation error Mathias Kretschmer
2003-11-15 12:29 ` 2.4.23-pre8-pac1 and -rc1-pac1 NFSv3 problem Greg Louis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031204224132.GA1906@unicorn.sch.bme.hu \
--to=pozsy@uhulinux.hu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.