Re: NFS client fcntl locks going missing on FC6

I have found out what was causing the bug I was seeing. The do_setlk
function of fs/nfs/file.c creates a local lock if the remote lock attempt
was blocked and then interrupted, supposedly so that the remote lock is
removed when the process exits. Unfortunately by this stage the lock has
forgotten how to do this, and if the process tries again for the same
remote lock and succeeds in getting it, the system reuses the existing
local only lock rather than creating a new one, which means that there is
apparently nothing using the owner records storing the (new) svid, and
this is information is discarded. As a result, when the file is unlocked,
there is no record of the svid that was used, so the unlock attempt uses a
new svid which of course fails, and the file is never unlocked.
I have attached a patch to the RedHat bugzilla bug (229469)
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148974
which under limited testing fixes the problem I was seeing by not creating
the local lock if it has no hope of removing any possible remote one,
though I suspect more thought could yield a better patch.

	Michael Young

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH 09/11] nfs-utils: mount: Fixed mounts to multi-home servers

On Tuesday February 27, jlayton <at> poochiereds.net wrote:
> 
> I know we saw this with Solaris servers in particular (it's been a 
> while, but I think I was testing against Solaris 8). The fedora BZ is 
> here if you want to see all the gory details:
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212471
> 
> I'm thinking we will have to deal with this situation, unfortunately, so 
> maybe disconnecting the socket after getting the address is the best thing?
> 
> -- Jeff

Thanks for the link... Looks like we do need to be very careful about
connecting UDP sockets.

This patch maybe?

NeilBrown

diff --git a/support/include/conn.h b/support/include/conn.h
index 1761dc4..11f16ab 100644
--- a/support/include/conn.h
+++ b/support/include/conn.h
 <at>  <at>  -35,7 +35,7  <at>  <at>  int clnt_ping(struct sockaddr_in *, const u_long, const u_long, const u_int,
 	      struct sockaddr_in *);
 u_long nfsvers_to_mnt(const u_long);
 u_long mntvers_to_nfs(const u_long);
-int get_socket(struct sockaddr_in *, u_int, int);
+int get_socket(struct sockaddr_in *, u_int, int, int);

Re: [PATCH 11/11] nfs-utils: mount: Fixed collision between commas in options

On Thu, Mar 01, 2007 at 10:33:53AM +1100, Neil Brown wrote:
> On Tuesday February 27, kzak <at> redhat.com wrote:
> > On Tue, Feb 27, 2007 at 05:35:58PM +1100, Neil Brown wrote:
> > > On Monday February 26, SteveD <at> redhat.com wrote:
> > > > commit 96a3ceb3d35bf5edcb9446aded8375d3b98b4f5b
> > > > Author: Cory Olmo <colmo <at> TrustedCS.com>
> > > > Date:   Sat Feb 24 16:20:40 2007 -0500
> > > > 
> > > >     This patch avoid the collision between commas in security contexts and the
> > > >     delimiter betweeen mount options.
> > > >     
> > > >     Signed-off-by: Karel Zak <kzak <at> redhat.com>
> > > >     Signed-off-by: Cory Olmo <colmo <at> TrustedCS.com>
> > > > 
> > > > diff --git a/utils/mount/mount.c b/utils/mount/mount.c
> > > > index b3d3696..f22747b 100644
> > > > --- a/utils/mount/mount.c
> > > > +++ b/utils/mount/mount.c
> > > >  <at>  <at>  -285,18 +285,30  <at>  <at>  static void parse_opts (const char *options, int *flags, char **extra_opts)
> > > >  {
> > > >  	if (options != NULL) {
> > > >  		char *opts = xstrdup(options);
> > > > -		char *opt;
> > > > -		int len = strlen(opts) + 20;
> > > > -
> > > > +		char *opt, *p;
> > > > +		int len = strlen(opts) + 256;
> > > 
> > > This is a worry.  If 20 isn't big enough, why do you thing 256 will
> > 

Re: nfs_update_inode: inode 309229856 mode changed, 0100644 to 0040755 - kernel 2.6.13.4

On 26/02/07, Jesper Juhl <jesper.juhl <at> gmail.com> wrote:
> I have a webserver running a rather old 2.6.13.4 kernel that a few
> minutes ago surprised me by logging the following message :
>
>  kernel: nfs_update_inode: inode 309229856 mode changed, 0100644 to 0040755
>
I just got one more of these (well, slightly different, but same basic
issue). This time it was one of my mailservers, also running 2.6.13.4.

  kernel: nfs_update_inode: inode -1073741693 mode changed, 0040700 to 0100644

> The server exporting the filesystem is running 2.6.18.1 (knfsd) -
> nothing is logged on the server...
>
This time it's a different NFS server (still using knfsd), this one is
running kernel 2.6.20. Still nothing logged at the server side.

> So a file changed type and permissions out of the blue.  A few
> questions about that:
>
> Any way I can identify the file (or is it a dir now ;) ?
> Does anyone know if this is a known bug that's been fixed? I couldn't
> find anything via google or git that looked like a fix.
>
These questions still apply 

--

-- 
Jesper Juhl <jesper.juhl <at> gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

nfs-client 2.6.20 bizarre ro-mount

Hello,

I have a rather bizare problems with the nfs-client in
Linux 2.6.20, the previously used kernel 2.6.17 worked fine:

For one specific filesystem, which is exported rw, the client
mounts the filesystem (according to /proc/mounts) as ro 
despite the fact that the mount-command asks to mount
it rw.

When doing a "mount -o remount,rw ..." after the first mount
the filesystem is writable and all is fine (and /proc/mounts
shows the mountpoint as "rw").

To make things more interesting, when doing a second mount
after the rw-remount, the mount is writable. So it seems 
that the _first_ mount for the mountpoint fails.

The mountpoint is located in a ramdisc.

The problem does not happen with client kernel 2.6.17. The 
configuration besides the kernel is unchanged. It only happens
with one filesystem, other filesystems from the same server
are mounted rw as requested. For us it is always reproducible
for all our clients. I found nothing special for this problematic
filesystem.

Server kernel is Linux vanilla 2.6.17 (unchanged), distribution
is Fedora Core 6 for client and server.

Re: [PATCH 06/11] nfs-utils: mount: AUTH_NONE mounts

Neil Brown wrote:
> On Tuesday February 27, staubach <at> redhat.com wrote:
>   
>> Neil Brown wrote:
>>     
>>> On Monday February 26, SteveD <at> redhat.com wrote:
>>>   
>>>       
>>>> commit 0ffd74c990aca3761b79316d47e1b1778273681c
>>>> Author: Steve Dickson <steved <at> redhat.com>
>>>> Date:   Sat Feb 24 15:27:46 2007 -0500
>>>>
>>>>     Added support to specify the AUTH_NONE security flavor (i.e. -o sec=none)
>>>>     
>>>>         
>>> If you specify "-o sec=none" then data.pseudoflavor will == AUTH_NONE,
>>> but
>>>
>>>   
>>>       
>> This support is being added so that the client can mount a file system
>> which was exported with sec=none.
>>     
>
> Ok, so the Changelog comment could be improved...
>
>   
>> This loop is looking for AUTH_NONE in the list of authentication
>> flavors that the server supports and was returned through the MOUNT
>> protocol during mounting.

o'clock

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Linux client cache corruption, system call returning incorrectly

I'm having a serious client cache issue on recent kernels.  On 2.6.18 
and 2.6.20 (but /not/ 2.6.15.4) clients I'm seeing periodic file GETATTR 
or ACCESS calls that return fine from the server pass an ENOFILE up to 
the application.  It occurs against all NFS servers I've tested (2.6.18 
knfsd, OnTap 10.0.1, SpinOS 2.5.5p8).

The triggering usage stage is repeated stat'ing of a several hundred 
files that are opened read-only (but not close() or open()'ing it again) 
during runtime.  I have been unable to duplicate the usage into a 
bug-triggering testcase yet, but it is very easily triggered by an 
internal app.  Mounting the NFS filesystems with 'nocto' appears to 
mitigate the issue by about 50%, but does not completely get rid of it. 
  Also, using 2.6.20+ Trond's NFS_ALL patches and this one you supplied 
also slow the rate of errors, but not completely.

I'm rigging the application with an strace harness so I can track down 
specifically what ops are failing in production.  I can confirm that 
those errors I have witnessed under debug are NOT failing due to an NFS 
call returning where access is denied, or on an open(), it appears to be 
stat() of the file (usually several dozen or hundreds in sequence) that 
return ENOFILE, though the call should return sucess.

Any tips on using rpcdebug effectively?  I'm getting tremendous levels 
of info output with '-m nfs -s all', too much to parse well.

I'll update with some more hard data as I get further along, but want to 
see if a) anyone else has noticed this and working on a fix, and b) if 
there are any suggestions on getting more useful data than what I'm 
working towards.

Reverting to 2.6.15.4 (which doesn't exhibit this particular bug) isn't 
a direct solution even temporarily, as that has a nasty NFS fseek bug 
(seek to EOF goes to wrong offset).

Cheers,

/eli

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH 06/11] nfs-utils: mount: AUTH_NONE mounts

On Thursday March 1, staubach <at> redhat.com wrote:
> 
> This was used to address RH bz187370.

Thanks for the link.  It provides good context.

I would have thought the appropriate response would have been the
following patch, and a suggestion to use
  mount -o sec=none .....
to mount the filesystem.
Do you see a problem with that?

NeilBrown

--- a/utils/mount/nfsmount.c
+++ b/utils/mount/nfsmount.c
 <at>  <at>  -638,7 +638,9  <at>  <at>  parse_options(char *old_opts, struct nfs_mount_data *data,
 				if (nfs_mount_version < 5) {
 					printf(_("Warning: ignoring sec=%s option\n"), secflavor);
 					continue;
-				} else if (!strcmp(secflavor, "sys"))
+				} else if (!strcmp(secflavor, "none"))
+					data->pseudoflavor = AUTH_NONE;
+				else if (!strcmp(secflavor, "sys"))
 					data->pseudoflavor = AUTH_SYS;
 				else if (!strcmp(secflavor, "krb5"))
 					data->pseudoflavor = AUTH_GSS_KRB5;

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

[PATCH 000 of 3] knfsd: Resolve IPv6 related link error

Current mainline has a compile linkage problem if both
  CONFIG_IPV6=m
  CONFIG_SUNRPC=y

because net/sunrpc/svcsock.c conditionally used a function defined in the IPv6 module.

These three patches resolve the issue.

The problem is caused because svcsock needs to get the source and
destination address for a udp packet, but doesn't want to just use
sock_recvmsg like userspace would as it wants to be able to use the
data directly out of the skbuff rather than copying it (when practical).

Currently it copies code from udp.c (both ipv4/ and ipv6/) and this
causes the problem.

This patch changes it to use kernel_recvmsg with a length of 0 and
flags of MSG_PEEK to get the addresses but leave the data untouched.

A small problem here is that kernel_recvmsg always checks the
checksum, so in the case of a large packet we will check the checksum
at a different time to when we copy it out into a buffer, which is not ideal.

So the second patch of this series avoids the check when recv_msg is
called with size==0 and flags==MSG_PEEK.  This change should be acked
by someone on netdev before going upsteam!!!  The rest of the series
is still appropriate without the patch, it is just a small
optimisation.

Finally the last patch removes all the
  #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
from sunrpc as it really isn't needed and just hides this sort of problem.

Patches 1 and 3 are suitable for 2.6.21.  Patch 2 needs confirmation.

Thanks,
NeilBrown

 [PATCH 001 of 3] knfsd: Use recv_msg to get peer address for NFSD instead of code-copying
 [PATCH 002 of 3] knfsd: Avoid checksum checks when collecting metadata for a UDP packet.
 [PATCH 003 of 3] knfsd: Remove CONFIG_IPV6 ifdefs from sunrpc server code.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html