gmane.linux.nfs

[PATCH] nfsidmap: idmapd.conf.5 man warnings

Aníbal Monsalve Salazar — 2013-05-25T02:12:48

I'm using the patch in this message to build libnfsidmap in Debian.

The following command:

 MANROFFSEQ='' MANWIDTH=80 man --warnings -l -Z ./idmapd.conf.5 >/dev/null 

shows the following warnings:

 <standard input>:237: warning: macro `"' not defined
 <standard input>:269: warning: macro `fo' not defined
 <standard input>:278: warning: macro `".SH' not defined

and the patch below fixes them.

--- a/idmapd.conf.52011-12-06 07:28:10.000000000 +1100
+++ b/idmapd.conf.52013-05-25 11:07:37.000000000 +1000
< at >< at > -31,7 +31,7 < at >< at >
 .\"
 .TH idmapd.conf 5 "19 Nov 2008"
 .SH NAME
-idmapd.conf
+idmapd.conf \- configuration file for libnfsidmap
 .SH SYNOPSIS
 Configuration file for libnfsidmap.  Used by idmapd and svcgssd to map NFSv4 name to and from ids.
 .SH DESCRIPTION
< at >< at > -234,7 +234,6 < at >< at > Number of seconds before timing out an L
 .\" -------------------------------------------------------------------
 .\"
 .SH EXAMPLES
-."
 An example
 .I /etc/idmapd.conf
 file:
< at >< at > -266,7 +265,6 < at >< at > johndoe-B7+jWCUtYZGJ7eWL8UQsWQ< at >public.gmane.org = johnny
 LDAP_server = ldap.domain.org
 LDAP_base = dc=org,dc=domain
 
-.fo
 .\"
 .\" -------------------------------------------------------------------
 .\" Additional sections
< at >< at > -275,11 +273,11 < at >< at > LDAP_base = dc=org,dc=domain
 .SH SEE ALSO
 .BR idmapd (8)
 .BR svcgssd (8)
-.".SH COMPATIBILITY
-.".SH STANDARDS
-.".SH ACKNOWLEDGEMENTS
-.".SH AUTHORS
-.".SH HISTORY
+.\".SH COMPATIBILITY
+.\".SH STANDARDS
+.\".SH ACKNOWLEDGEMENTS
+.\".SH AUTHORS
+.\".SH HISTORY
 .SH BUGS
 Report bugs to <nfsv4-6DNke4IJHB0gsBAKwltoeQ< at >public.gmane.org>
-.".SH CAVEATS
+.\".SH CAVEATS
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] svcrpc: implement O_NONBLOCK behavior for use-gss-proxy

J. Bruce Fields — 2013-05-24T22:12:28

From: "J. Bruce Fields" <bfields-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>

Somebody noticed LTP was complaining about O_NONBLOCK opens of
/proc/net/rpc/use-gss-proxy succeeding and then a following read
hanging.

I'm not convinced LTP really has any business opening random proc files
and expecting them to behave a certain way.  And I don't really know if
this is really a bug.

But in any case perhaps the O_NONBLOCK behavior could be useful for
someone that wants to test whether gss-proxy is up without waiting.

Reported-by: Jan Stancek <jstancek-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
Signed-off-by: J. Bruce Fields <bfields-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
---
 net/sunrpc/auth_gss/svcauth_gss.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Considering for 3.10.

diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcauth_gss.c
index 9f0f017..618ccf5 100644
--- a/net/sunrpc/auth_gss/svcauth_gss.c
+++ b/net/sunrpc/auth_gss/svcauth_gss.c
< at >< at > -1313,10 +1313,12 < at >< at > static inline bool gssp_ready(struct sunrpc_net *sn)
 return false;
 }
 
-static int wait_for_gss_proxy(struct net *net)
+static int wait_for_gss_proxy(struct net *net, struct file *file)
 {
 struct sunrpc_net *sn = net_generic(net, sunrpc_net_id);
 
+if (file->f_flags & O_NONBLOCK && !gssp_ready(sn))
+return -EAGAIN;
 return wait_event_interruptible(sn->gssp_wq, gssp_ready(sn));
 }
 
< at >< at > -1358,7 +1360,7 < at >< at > static ssize_t read_gssp(struct file *file, char __user *buf,
 size_t len;
 int ret;
 
-ret = wait_for_gss_proxy(net);
+ret = wait_for_gss_proxy(net, file);
 if (ret)
 return ret;

[PATCH] svcrpc: fix failures to handle -1 uid's and gid's

J. Bruce Fields — 2013-05-24T22:05:49

From: "J. Bruce Fields" <bfields-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>

As of f025adf191924e3a75ce80e130afcd2485b53bb8 "sunrpc: Properly decode
kuids and kgids in RPC_AUTH_UNIX credentials" any rpc containing a -1
(0xffff) uid or gid would fail with a badcred error.

Reported symptoms were xmbc clients failing on upgrade of the NFS
server; examination of the network trace showed them sending -1 as the
gid.

Reported-by: Julian Sikorski <belegdol-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
Cc: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w< at >public.gmane.org>
Signed-off-by: J. Bruce Fields <bfields-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
---
 net/sunrpc/svcauth_unix.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/net/sunrpc/svcauth_unix.c b/net/sunrpc/svcauth_unix.c
index c3f9e1e..06bdf5a 100644
--- a/net/sunrpc/svcauth_unix.c
+++ b/net/sunrpc/svcauth_unix.c
< at >< at > -810,11 +810,15 < at >< at > svcauth_unix_accept(struct svc_rqst *rqstp, __be32 *authp)
 goto badcred;
 argv->iov_base = (void*)((__be32*)argv->iov_base + slen);/* skip machname */
 argv->iov_len -= slen*4;
-
+/*
+ * Note: we skip uid_valid()/gid_valid() checks here for
+ * backwards compatibility with clients that use -1 id's.
+ * Instead, -1 uid or gid is later mapped to the
+ * (export-specific) anonymous id by nfsd_setuser.
+ * Supplementary gid's will be left alone.
+ */
 cred->cr_uid = make_kuid(&init_user_ns, svc_getnl(argv)); /* uid */
 cred->cr_gid = make_kgid(&init_user_ns, svc_getnl(argv)); /* gid */
-if (!uid_valid(cred->cr_uid) || !gid_valid(cred->cr_gid))
-goto badcred;
 slen = svc_getnl(argv);/* gids length */
 if (slen > 16 || (len -= (slen + 2)*4) < 0)
 goto badcred;
< at >< at > -823,8 +827,6 < at >< at > svcauth_unix_accept(struct svc_rqst *rqstp, __be32 *authp)
 return SVC_CLOSE;
 for (i = 0; i < slen; i++) {
 kgid_t kgid = make_kgid(&init_user_ns, svc_getnl(argv));
-if (!gid_valid(kgid))
-goto badcred;
 GROUP_AT(cred->cr_group_info, i) = kgid;
 }
 if (svc_getu32(argv) != htonl(RPC_AUTH_NULL) || svc_getu32(argv) != 0) {

Re: [PATCH] Fix handling of preferred_realm command line option

Maximilian Wilhelm — 2013-05-24T13:48:58

Anno domini 2013 Maximilian Wilhelm scripsit:

Me again,




I felt the urge to update the comment, too :)

Best regards
Max

[PATCH] Fix handling of preferred_realm command line option

Maximilian Wilhelm — 2013-05-24T12:54:24

(Please CC me in replies, I'm not on the list.)

Hi,

we found a problem in the gssd daemon when using the -R opton to
specify a different preferred realm than the one used on the system.
It seems the preferred_realm variable set in the gssd.c file is not
used at all when searching for keytab entries / principal.

The simple patch attached fixes this problem.

Thanks
Max

Re: [PATCH RFC 1/1] NFS: Allow nfs_updatepage to extend a write to cover a full page when we have a lock that covers the entire file

Jeff Layton — 2013-05-24T11:24:03

On Thu, 23 May 2013 22:30:10 +0000
"Myklebust, Trond" <Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA< at >public.gmane.org> wrote:


Right, so I think we ought to be conservative here and not extend the
write if this is an F_RDLCK.


True, but it's probably still preferable to do that than to do a bunch
of small I/Os to the server. But, that's an optimization that can be
done later. Hardly anyone does real byte-range locking so I'm fine with
this approach for now.


Yes, that would be a good thing too. Having a helper function like you
suggested should make it easier to encapsulate that logic sanely.

RE: [PATCH] nfs: support 64-bit root inode number in NFS FSID

Myklebust, Trond — 2013-05-24T01:49:12

unsigned long long is guaranteed by C99 to be >= 64 bits. IOW: it could be 128 bits depending on the compiler.


--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] nfs: support 64-bit root inode number in NFS FSID

Yong, Fan — 2013-05-24T01:30:23

For the rare unfortunate cases of "sizeof(unsigned long) < 4" or "sizeof(unsigned long long) < 8", current nfs-utils will cross-boundary memory copy. So need more work to make it stably runnable on kinds of platform...

--
Cheers,
Nasf

-----Original Message-----
From: Myklebust, Trond [mailto:Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA< at >public.gmane.org] 
Sent: Thursday, May 23, 2013 10:22 PM
To: Jim Rees
Cc: Yong, Fan; Peng Tao; Dilger, Andreas; J. Bruce Fields; linux-nfs-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org; Steve Dickson
Subject: RE: [PATCH] nfs: support 64-bit root inode number in NFS FSID


Yes. It's not guaranteed to be 64-bit either.

Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 1/1] NFS: Allow nfs_updatepage to extend a write to cover a full page when we have a lock that covers the entire file

Myklebust, Trond — 2013-05-23T22:30:10

I'm guessing that the answer is to both these questions are "no":
- Anybody who is writing while holding a F_RDLCK is likely doing
something wrong.
- Walking the lock list on every write can quickly get painful if we
have lots of small locks.

However it may make a lot of sense to look at whether or not we hold a
NFSv4 write delegation.

Re: [PATCH RFC 1/1] NFS: Allow nfs_updatepage to extend a write to cover a full page when we have a lock that covers the entire file

Jeff Layton — 2013-05-23T22:24:50

On Thu, 23 May 2013 17:53:41 -0400
Scott Mayhew <smayhew-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org> wrote:


Sounds like a reasonable proposition, but I think you might need to do
more vetting of the locks...

For instance, does it make sense to do this if it's a F_RDLCK? Also,
you're only looking at the first lock in the i_flock list. Might it
make more sense to walk the list and see whether the page might be
entirely covered by a lock that doesn't extend over the whole file?

Re: [PATCH RFC 1/1] NFS: Allow nfs_updatepage to extend a write to cover a full page when we have a lock that covers the entire file

Myklebust, Trond — 2013-05-23T22:15:34

Hi Scott,

On Thu, 2013-05-23 at 17:53 -0400, Scott Mayhew wrote:

Can we put this condition into a helper function? I started with the
"nfs_write_pageuptodate()" thingy, but now we're starting to add in
extra complications...

Thanks!
  Trond

[PATCH RFC 1/1] NFS: Allow nfs_updatepage to extend a write to cover a full page when we have a lock that covers the entire file

Scott Mayhew — 2013-05-23T21:53:41

Currently nfs_updatepage allows a write to be extended to cover a full
page only if we don't have a byte range lock on the file... but if we've
got the whole file locked, then we should be allowed to extend the
write.

Signed-off-by: Scott Mayhew <smayhew-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
---
 fs/nfs/write.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index a2c7c28..f35fb4f 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
< at >< at > -908,13 +908,16 < at >< at > int nfs_updatepage(struct file *file, struct page *page,
 file->f_path.dentry->d_name.name, count,
 (long long)(page_file_offset(page) + offset));
 
-/* If we're not using byte range locks, and we know the page
+/* If we're not using byte range locks (or if the range of the
+ * lock covers the entire file), and we know the page
  * is up to date, it may be more efficient to extend the write
  * to cover the entire page in order to avoid fragmentation
  * inefficiencies.
  */
 if (nfs_write_pageuptodate(page, inode) &&
-inode->i_flock == NULL &&
+(inode->i_flock == NULL ||
+(inode->i_flock->fl_start == 0 &&
+inode->i_flock->fl_end == OFFSET_MAX)) &&
 !(file->f_flags & O_DSYNC)) {
 count = max(count + offset, nfs_page_length(page));
 offset = 0;

[PATCH RFC 0/1] Allow nfs_updatepage to extend a write to cover a full page when we have a lock that covers the entire file

Scott Mayhew — 2013-05-23T21:53:40

We had a customer experience some performance issues after migrating their
MQseries servers from AIX to Linux.  Their performance benchmark basically puts
50000 messages in a message queue, and a tcpdump captured during these tests
would show a ton of very small writes that were sequential but not contiguous.
After doing some investigation with systemtap we determined that when we called
nfs_updatepage() we were not being allowed to extend the write because the
inode->i_flock was not NULL.  So then later when we'd arrive at
nfs_try_to_update_request() we would always wind up calling nfs_wb_page().

I gave the customer a test kernel using a patch similar to the one that follows
and the test results were favorable, with far fewer writes, the majority of
which were utilizing the full wsize.  For example, the top ten write sizes and
number of occurrences from a tcpdump captured while running the benchmark with
an unpatched kernel:

$ tshark -r before.pcap.gz -R "nfs.opcode==write && nfs.stateid4.hash==0xf09c"
-T fields -e nfs.write.data_length | sort | uniq -c | sort -nr | head
   5852 512
   5575 1024
   2262 1035
   2160 1121
   1661 1023
   1460 1074
   1413 1073
   1394 1152
   1244 1055
    933 1804

contrasted with a tcpdump captured while running the benchmark with the test
kernel:

$ tshark -r after.pcap.gz -R "nfs.opcode==write && nfs.stateid4.hash==0x9f87"
-T fields -e nfs.write.data_length | sort | uniq -c | sort -nr | head
    917 65536
     76 36864
     69 20480
     55 53248
     32 18432
     31 49152
     31 4096
     31 32768
     30 16384
     25 65536,4096

Scott Mayhew (1):
  NFS: Allow nfs_updatepage to extend a write to cover a full page when
    we     have a lock that covers the entire file

 fs/nfs/write.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

Plank House available for Bakeathon

Jim Rees — 2013-05-23T21:49:48

If you are coming to the Bakeathon in Ann Arbor, and don't want to stay at a
corporate hotel on the edge of town, you might consider staying at the
historic Plank Road Tollhouse. It's right on Main Street, a 15 minute walk
through leafy neighborhoods to the Bakeathon site, and close to Ann Arbor's
best ice cream. It's got a DSL line and wireless router and I'll throw in an
NFS server if that makes a difference. It's also got a big garage and 200
amp service for those of you who want to set up a data center during your
stay. My wife and I own it and she's an excellent innkeeper. Contact me or
check it out on vrbo:
http://www.vrbo.com/370725
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] nfs: support 64-bit root inode number in NFS FSID

Myklebust, Trond — 2013-05-23T14:21:45

Yes. It's not guaranteed to be 64-bit either.

Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] nfs: support 64-bit root inode number in NFS FSID

Jim Rees — 2013-05-23T14:20:10

  On Thu, 2013-05-23 at 12:59 +0000, Yong, Fan wrote:
  > Just make it match the "inode64" in nfs-utils parse_fsid(), which is defined as "unsigned long long", and the parsed_fsid:: inode is copied from "inode64" as following:
  > 
  > static int parse_fsid(int fsidtype, int fsidlen, char *fsid,
  >                 struct parsed_fsid *parsed)
  > {
  >         unsigned int dev;
  >         unsigned long long inode64;
  > ...
  >         case FSID_UUID16_INUM: /* 8 byte inode number and 16 byte uuid */
  >                 if (fsidlen != 24)
  >                         return -1;
  >                 memcpy(&inode64, fsid, 8);
  >                 parsed->inode = inode64;
  >                 parsed->uuidlen = 16;
  >                 parsed->fhuuid = fsid+8;
  >                 break;
  >         }
  > 
  > --
  > Cheers,
  > Nasf
  
  Eeeeeeeewww! This is _exactly_ why we should be using properly
  dimensioned types. Feel free to tell me how the value of 'inode64' is
  well defined on systems where sizeof(unsigned long long) != 8...

Is there any reason not to use ino_t?
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] nfs: support 64-bit root inode number in NFS FSID

Myklebust, Trond — 2013-05-23T13:39:40

Eeeeeeeewww! This is _exactly_ why we should be using properly
dimensioned types. Feel free to tell me how the value of 'inode64' is
well defined on systems where sizeof(unsigned long long) != 8...

Trond

RE: [PATCH] nfs: support 64-bit root inode number in NFS FSID

Yong, Fan — 2013-05-23T12:59:34

Just make it match the "inode64" in nfs-utils parse_fsid(), which is defined as "unsigned long long", and the parsed_fsid:: inode is copied from "inode64" as following:

static int parse_fsid(int fsidtype, int fsidlen, char *fsid,
                struct parsed_fsid *parsed)
{
        unsigned int dev;
        unsigned long long inode64;
...
        case FSID_UUID16_INUM: /* 8 byte inode number and 16 byte uuid */
                if (fsidlen != 24)
                        return -1;
                memcpy(&inode64, fsid, 8);
                parsed->inode = inode64;
                parsed->uuidlen = 16;
                parsed->fhuuid = fsid+8;
                break;
        }

--
Cheers,
Nasf



-----Original Message-----
From: Myklebust, Trond [mailto:Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA< at >public.gmane.org] 
Sent: Thursday, May 23, 2013 8:50 PM
To: Peng Tao
Cc: Dilger, Andreas; J. Bruce Fields; linux-nfs-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org; Yong, Fan; Steve Dickson
Subject: Re: [PATCH] nfs: support 64-bit root inode number in NFS FSID

On Thu, 2013-05-23 at 16:12 +0800, Peng Tao wrote:

Why not just specify a uint64_t size then?

--
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA< at >public.gmane.org
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] nfs: support 64-bit root inode number in NFS FSID

Myklebust, Trond — 2013-05-23T12:49:43

Why not just specify a uint64_t size then?

Re: [PATCH] nfs: support 64-bit root inode number in NFS FSID

Peng Tao — 2013-05-23T08:12:04

[nfs-utils patch needs to be sent to Steve Dickson (CC'ed)]

On Thu, May 23, 2013 at 7:06 AM, Dilger, Andreas
<andreas.dilger-ral2JQCrhuEAvxtiuMwx3w< at >public.gmane.org> wrote:
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] nfs: support 64-bit root inode number in NFS FSID

Dilger, Andreas — 2013-05-22T23:06:54

When exporting a filesystem via NFS, it can generate several kinds
of NFS filesystem IDs. For most of cases, it uses a 32-bit inode
number in the NFS FSID, but this does not work on a filesystem
using a 64-bit root inode number.

In kernel space, NFS can generate/use NFS FSID with a 64-bit inode
number for the "FSID_UUID16_INUM" type. Unfortunately, while the
user space nfs-utils decode the 64-bit inode number from the FSID
correctly, it is truncated when storing it in "struct parsed_fsid".
Expand the "struct parsed_fsid" inode field to store the full 64-bit
root inode number.

Intel-bug-id: LU-2904
Signed-off-by: Fan Yong <fan.yong-ral2JQCrhuEAvxtiuMwx3w< at >public.gmane.org>
Signed-off-by: Andreas Dilger <andreas.dilger-ral2JQCrhuEAvxtiuMwx3w< at >public.gmane.org>
---
 utils/mountd/cache.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
index 517aa62..a7212e7 100644
--- a/utils/mountd/cache.c
+++ b/utils/mountd/cache.c
< at >< at > -388,7 +388,7 < at >< at > struct parsed_fsid {
 int fsidtype;
 /* We could use a union for this, but it would be more
  * complicated; why bother? */
-unsigned int inode;
+unsigned long long inode; /* We need 64-bits ino# */
 unsigned int minor;
 unsigned int major;
 unsigned int fsidnum;
--1.7.1

Patch is also attached separately, since it will likely be butchered
by this email client.


Cheers, Andreas