<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel about="http://blog.gmane.org/gmane.linux.nfs">
    <title>gmane.linux.nfs</title>
    <link>http://blog.gmane.org/gmane.linux.nfs</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23459"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23457"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23447"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23442"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23435"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23434"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23427"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23425"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23420"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23418"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23414"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23412"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23391"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23385"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23384"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23379"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23365"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23363"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23355"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfs/23353"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23459">
    <title>[patch 1/1] lockd: convert reclaimer thread to kthread interface</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23459</link>
    <description>From: Jeff Layton &lt;jlayton-H+wXaHxf7aLQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt;

My understanding is that there is a push to turn the kernel_thread
interface into a non-exported symbol and move all kernel threads to use
the kthread API. This patch changes lockd to use kthread_run to spawn
the reclaimer thread.

I've made the assumption here that the extra module references taken
when we spawn this thread are unnecessary and removed them. I've also
added a KERN_ERR printk that pops if the thread can't be spawned to warn
the admin that the locks won't be reclaimed.

In the future, it would be nice to be able to notify userspace that
locks have been lost (probably by implementing SIGLOST), and adding some
good policies about how long we should reattempt to reclaim the locks.

Finally, I removed a comment about memory leaks that I believe is
obsolete and added a new one to clarify the result of sending a SIGKILL
to the reclaimer thread. As best I can tell, doing so doesn't actually
cause a memory leak.

Signed-off-by: Jeff </description>
    <dc:creator>akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2008-12-01T22:27:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23457">
    <title>[NFS] D entists Contact List for the USA</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23457</link>
    <description>

Comes with unlimited use license and at a very resonable price:

--&gt; 164,574 |&gt;entists 
--&gt; 158,242 Physical Addresses
--&gt; 163,185 Phone Numbers
--&gt; 77,878 Office Fax Numbers 
--&gt; 45,954 e mails

only during this week you won't pay the regular $593 price, you get it for $296

Write an email to Monroe-YiFMxoQ3Mhodw2Fo+rOw49BPR1lH4CV8&lt; at &gt;public.gmane.org for additional info 




to get off please email exclude-YiFMxoQ3Mhodw2Fo+rOw49BPR1lH4CV8&lt; at &gt;public.gmane.org



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK &amp; win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&amp;url=/
_______________________________________________
NFS maillist  -  NFS-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org
https://lists.sourceforge.net/lists/listinfo/nfs
___________________________</description>
    <dc:creator>Strong O Karin</dc:creator>
    <dc:date>2008-12-01T22:04:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23447">
    <title>[PATCH 0/6] First set of patches for 2.6.29</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23447</link>
    <description>These patches add some IPv6 support to the Linux kernel's NSM upcall
implementation, and address a couple of shortcomings in the existing
NLM/NSM implementation.

I'd like you to consider these for 2.6.29.

There are 40 more patches I have queued for 2.6.29 that finish IPv6
support in the NSM upcall implementation, enable IPv6 for lockd, and
finish and enable IPv6 support in NFSD.

---

Chuck Lever (6):
      NSM: Serialize SM_MON and SM_UNMON upcalls
      NLM: Clean up nsm_monitor() call
      NLM: Clean up nsm_monitor() call
      NSM: Support IPv6 version of mon_name
      NLM: Support IPv6 scope IDs in nlm_display_address()
      NLM: Remove address eye-catcher buffers from nlm_host


 fs/lockd/host.c                |   53 ++++++++++--------
 fs/lockd/mon.c                 |  120 +++++++++++++++++++++-------------------
 include/linux/lockd/lockd.h    |   21 ++++++-
 include/linux/lockd/sm_inter.h |    2 -
 4 files changed, 109 insertions(+), 87 deletions(-)

</description>
    <dc:creator>Chuck Lever</dc:creator>
    <dc:date>2008-12-01T18:57:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23442">
    <title>[PATCH 0/4] Make mount.nfs use new getport() function</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23442</link>
    <description>Hi Steve-

Four new IPv6-related patches for mount.nfs.  These replace the
existing PMAP_GETPORT implementation in utils/mount/network.c with a
call to the new library functions we just added.

The probe_statd() function is used by both the legacy and the text-
based paths, but replacing the mount.nfs command's getport() function
affects only the *legacy* NFS mount path, not text-based mounts.

For anyone testing this code, please try it on pre-2.6.23 kernels,
or patch mount.nfs to use legacy binary style mounts.  This will
exercise the new PMAP_GETPORT implementation using all the special
cases needed by mount.nfs.

The new RPCB_GETADDR implementation will not be used until mount.nfs
can pass in IPv6 addresses.

---

Chuck Lever (4):
      mount command: remove local getport() implementation
      mount command: Replace clnt_ping() and getport() calls in probe_port()
      mount command: Use nfs_error() instead of perror()
      mount command: Use nfs_pmap_getport() in probe_statd()


 utils/mount/network.c</description>
    <dc:creator>Chuck Lever</dc:creator>
    <dc:date>2008-12-01T18:48:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23435">
    <title>[PATCH] nfs: remove redundant tests on reading new pages</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23435</link>
    <description>aops-&gt;readpages() and its NFS helper readpage_async_filler() will only
be called to do readahead I/O for newly allocated pages. So it's not
necessary to test for the always 0 dirty/uptodate page flags.

The removal of nfs_wb_page() call also fixes a readahead bug: the NFS
readahead has been synchronous since 2.6.23, because that call will
clear PG_readahead, which is the reminder for asynchronous readahead.

More background: the PG_readahead page flag is shared with PG_reclaim,
one for read path and the other for write path. clear_page_dirty_for_io()
unconditionally clears PG_readahead to prevent possible readahead residuals,
assuming itself to be always called in the write path. However, NFS is one
and the only exception in that it _always_ calls clear_page_dirty_for_io()
in the read path, i.e. for readpages()/readpage().

Cc: Trond Myklebust &lt;Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt;
Signed-off-by: Wu Fengguang &lt;wfg-VuQAYsv1563Yd54FQh9/CA&lt; at &gt;public.gmane.org&gt;
---
 fs/nfs/read.c |    6 ------
 1</description>
    <dc:creator>Wu Fengguang</dc:creator>
    <dc:date>2008-12-01T03:19:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23434">
    <title>ipv6 status</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23434</link>
    <description>Hi All,

So what exactly is the status of NFS and IPv6 in the most recent (say,
2.6.24-28) kernels?  Is it present and if so, working?  Feel free to
simply point me to a roadmap that shows where we are if you like.

Cheers and thanx,
b.

</description>
    <dc:creator>Brian J. Murrell</dc:creator>
    <dc:date>2008-12-01T00:40:16</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23427">
    <title>No write access with recent versions of nfs-utils in Debian</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23427</link>
    <description>This appears to be a Debian-specific issue, so I'm just looking for a 
pointer from someone who may know about it.

I installed Debian sid on a new machine back in July, including the 
current nfs-common and nfs-kernel-server.  NFS mounts were successful, 
but did not allow write -- I lost some serious data on one occasion 
before I noticed the problem.  mount and nfs-utils were upgraded several 
times since, and never gave the requested write access. I've been 
assuming the problem was firewall-related and lived with it.

On the other machines in the group, NFS writes worked fine.  I banged my 
head against the wall for a while today, after finally finding time to 
look into the problem, and discovered a completely different version of 
nfs-utils was running on the new machine. After a painful downgrade 
things work fine again. 

Here's the verbose output of the version that didn't work, nfs-common  
1:1.1.3-2:

mount -vvv /mnt/cortona1
mount: fstab path: "/etc/fstab"
mount: lock path:  "/etc/mtab~"
mount: </description>
    <dc:creator>David Liontooth</dc:creator>
    <dc:date>2008-11-30T22:13:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23425">
    <title>Is order for "exportfs -r" and rpc.mountd important?</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23425</link>
    <description>According to manual page "exportfs -r" has two modes: legacy and new. Fedora 
10 seems to use the new mode and mounts /proc/fs/nfsd.

But they use the following order in /etc/init.d/nfs:
  exportfs -r
  rpc.mountd

This results in /proc/fs/nfsd/exports having all obsolete entries 
from /var/lib/nfs/rmtab which causes a lot of trouble with stale NFS file 
handles. This seems to be wrong according to "man exportfs" in new mode.

If I change the order to
  rpc.mountd
  exportfs -r

then everything is OK and /proc/fs/nfsd/exports only contains the info 
from /etc/exports and not all stale clients. This seems to be correct 
according to "man exportfs" in new mode.

Questions: is this behaviour a bug or at least bad? Shouldn't exportfs being 
changed, so that when it detects "new" mode it will never feed rmtab into the 
kernel and rely upon rpc.mountd answering the kernels questions as stated 
in "man exportfs"?

If yes, then the order or the programs is irrelevant.
If not, should the order of the programs be reve</description>
    <dc:creator>Dr. Tilmann Bubeck</dc:creator>
    <dc:date>2008-11-28T14:41:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23420">
    <title>[PATCH 1/1] NFS: fix ERR_PTR with un mapped NFSv4 error</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23420</link>
    <description>From: Andy Adamson &lt;andros-HgOvQuBEEgTQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt;

NFSv4 errors need to be mapped prior to ERR_PTR.

Signed-off-by: Andy Adamson &lt;andros-HgOvQuBEEgTQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt;
---
 fs/nfs/client.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index 7547600..49f06ce 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
&lt; at &gt;&lt; at &gt; -1154,7 +1154,7 &lt; at &gt;&lt; at &gt; struct nfs_server *nfs4_create_server(const struct nfs_parsed_mount_data *data,
 error:
 nfs_free_server(server);
 dprintk("&lt;-- nfs4_create_server() = error %d\n", error);
-return ERR_PTR(error);
+return ERR_PTR(nfs4_map_errors(error));
 }
 
 /*
&lt; at &gt;&lt; at &gt; -1231,7 +1231,7 &lt; at &gt;&lt; at &gt; struct nfs_server *nfs4_create_referral_server(struct nfs_clone_mount *data,
 error:
 nfs_free_server(server);
 dprintk("&lt;-- nfs4_create_referral_server() = error %d\n", error);
-return ERR_PTR(error);
+return ERR_PTR(nfs4_map_errors(error));
 }
 
 #endif /* CONFIG_NFS_V4 */
&lt; at &gt;&lt; at &gt; -1299,7 +1299,7 &lt; at &gt;&lt; at &gt; struct nfs_server *nfs_c</description>
    <dc:creator>andros-HgOvQuBEEgTQT0dZR+AlfA&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2008-11-26T22:49:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23418">
    <title>[NFS] Comprehensive Healthcare Marketing List</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23418</link>
    <description>Certified Medical Doctors in the US 

Medical Doctors in many different specialties

you can sort by many different fields like city, state or zip

Regular price is $494 but this week you only pay: $399


~~~~~ These lists come at no charge when you order: ~~~~~

--&gt; Dentists

--&gt; Veterinarians

--&gt; Physical Therapists

--&gt; Visiting Nurses &amp; RN's

Email us at:: Benitez-Px9Zx9/iZEOakBO8gow8eQ&lt; at &gt;public.gmane.org
  
this offer is only valid until Nov 28, 2008 ==============   To invoke no further correspondence status please send an email to gone-Px9Zx9/iZEOakBO8gow8eQ&lt; at &gt;public.gmane.org



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK &amp; win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&amp;url=/
_______________________________________________
NFS maillist  -  NFS</description>
    <dc:creator>Elizabeth N Ritter</dc:creator>
    <dc:date>2008-11-26T17:36:41</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23414">
    <title>Patch to prevent rpc.gssd spamming logs when Kerberos credentials are expired</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23414</link>
    <description>Hi,

We've seen excessive (disk filling) log spam from rpc.gssd where users
mount their home directory via Kerberised NFS, and their Kerberos TGT
expires. You get lots of noise like described at
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/293705

Attached is the patch that we've been using to address this.

regards

Andrew

--
Andrew Pollock
Google Systems Administrator
</description>
    <dc:creator>Andrew Pollock</dc:creator>
    <dc:date>2008-11-25T21:22:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23412">
    <title>[NFS] Database of geriatric specialists and more</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23412</link>
    <description>Fully Licensed MDs in the US 

Coverage in many different areas of medicine such as Endocrinology, Pathology, Urology, Neurology, Plastic Surgery, Psychiatry, Cardiology and much more 

you can sort by many different fields like city, state or zip

This week's special price =  $394


***** Order this week and you will get at no charge: *****

&lt;&gt; Chiropractors

&lt;&gt; Physical Therapists

&lt;&gt; Massage Therapists

&lt;&gt; Acupuncturists

contact your rep:: Calhoun-Px9Zx9/iZEOakBO8gow8eQ&lt; at &gt;public.gmane.org
  
from now until Friday .   have a look at this if you don't like to recieve these kinds of emails please send an email to gone-Px9Zx9/iZEOakBO8gow8eQ&lt; at &gt;public.gmane.org



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK &amp; win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=1</description>
    <dc:creator>Harvey spiky</dc:creator>
    <dc:date>2008-11-25T15:56:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23391">
    <title>[PATCH] NLM: client-side nlm_lookup_host() should avoid matching onsrcaddr</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23391</link>
    <description>Since commit c98451bd, the loop in nlm_lookup_host() unconditionally
compares the host's h_srcaddr field to the incoming source address.
For client-side nlm_host entries, both are always AF_UNSPEC, so this
check is unnecessary.

Since commit 781b61a6, which added support for AF_INET6 addresses to
nlm_cmp_addr(), nlm_cmp_addr() now returns FALSE for AF_UNSPEC
addresses, which causes nlm_lookup_host() to create a fresh nlm_host
entry every time it is called on the client.

These extra entries will eventually expire once the server is
unmounted, so the impact of this regression, introduced with lockd
IPv6 support in 2.6.28, should be minor.

We could fix this by adding an arm in nlm_cmp_addr() for AF_UNSPEC
addresses, but really, nlm_lookup_host() shouldn't be matching on the
srcaddr field for client-side nlm_host lookups.

Signed-off-by: Chuck Lever &lt;chuck.lever-QHcLZuEGTsvQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt;
---

 fs/lockd/host.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/fs/lockd/hos</description>
    <dc:creator>Chuck Lever</dc:creator>
    <dc:date>2008-11-24T17:51:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23385">
    <title>[PATCH nfs-utils] Ensure statd gets started if required when non-root user mounts an NFS filesystem.</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23385</link>
    <description>
openSUSE-11.1 betas rely in mount.nfs to start statd when required.
This helped me discover that it doesn't work when a non-root user is
mounting a filesystem as the setuid status gets lots.
This patch fixes it.

Thanks,
NeilBrown



From 78d2001f031553ef90db708d5a7b3fbb9b31a873 Mon Sep 17 00:00:00 2001
From: Neil Brown &lt;neilb-l3A5Bk7waGM&lt; at &gt;public.gmane.org&gt;
Date: Mon, 24 Nov 2008 11:00:19 +1100
Subject: [PATCH] Ensure statd gets started if required when non-root user mounts an NFS filesystem.

The first time an NFS filesystem is mounted, we start statd from /sbin/mount.nfs.
If this first time is a non-root user doing the mount, (thanks to e.g. the
'users' option in /etc/fstab) then we need to be sure that the 'setuid' status
from mount.nfs is inherited through to rpc.statd so that it runs as root.

There are two places where we loose our setuid status due to the shell
(/bin/sh) discarding.

1/ mount.nfs uses "system" to run /usr/sbin/start-statd.  This runs a shell
  which is likely to drop privileges.  So c</description>
    <dc:creator>Neil Brown</dc:creator>
    <dc:date>2008-11-24T00:07:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23384">
    <title>[PATCH] svcsock: Add a reference to sunrpc in svc_addsock</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23384</link>
    <description>The svc_addsock function adds transport instances without taking a
reference on the sunrpc.ko module, however, the generic transport
destruction code drops a reference when a transport instance
is destroyed.

Add a try_module_get call to the svc_addsock function for transport
instances added by this function.

Signed-off-by: Tom Tucker &lt;tom-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW&lt; at &gt;public.gmane.org&gt;

---
 net/sunrpc/svcsock.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 95293f5..a1951dc 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
&lt; at &gt;&lt; at &gt; -1183,7 +1183,11 &lt; at &gt;&lt; at &gt; int svc_addsock(struct svc_serv *serv,
 else if (so-&gt;state &gt; SS_UNCONNECTED)
 err = -EISCONN;
 else {
-svsk = svc_setup_socket(serv, so, &amp;err, SVC_SOCK_DEFAULTS);
+if (!try_module_get(THIS_MODULE))
+err = -ENOENT;
+else
+svsk = svc_setup_socket(serv, so, &amp;err,
+SVC_SOCK_DEFAULTS);
 if (svsk) {
 struct sockaddr_storage addr;
 struct sockad</description>
    <dc:creator>Tom Tucker</dc:creator>
    <dc:date>2008-11-23T14:08:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23379">
    <title>[PATCH] NLM: AF_UNSPEC addresses are all equal</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23379</link>
    <description>The nlm_cmp_addr() function, which compares two IP addresses, is
sometimes used to check AF_UNSPEC addresses.  If both addresses are
AF_UNSPEC, then it should consider them equal -- the contents of an
AF_UNSPEC address, other than the address family, are
inconsequential.

This is important because the loop in nlm_lookup_host() always
compares the h_srcaddr field to the incoming source address.  For
client nlm_host entries, both are always AF_UNSPEC, and should allow
the entry match to succeed.  If it always fails, then we create a
fresh nlm_host entry every time we mount the same server, even if
all other items in the existing entry (protocol, NLM version, host
address) match.

These extra entries will eventually expire once the server is
unmounted, so the impact of this bug, introduced in 2.6.28 with
commit 781b61a6, should be minor.

Signed-off-by: Chuck Lever &lt;chuck.lever-QHcLZuEGTsvQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt;
---
Bruce-

Another minor lockd IPv6 bug fix for 2.6.28.

Alternate fix for this problem is to</description>
    <dc:creator>Chuck Lever</dc:creator>
    <dc:date>2008-11-22T16:58:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23365">
    <title>[NFS] General Dentists List in America</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23365</link>
    <description>

Just Released: for the USA

--&gt; 164,341 D entists 
--&gt; 158,048 Postal Addresses
--&gt; 163,958 Tel #'s
--&gt; 77,093 Fax Numbers
--&gt; 45,870 E-Mail Addresses

for only this week you can take the above with unlimited use rights for $297 - a $594 value

Write an email to Dalton-W3yqWAQfaE6Bik42HM7KXg&lt; at &gt;public.gmane.org for additional info 




By emailing release-W3yqWAQfaE6Bik42HM7KXg&lt; at &gt;public.gmane.org you will have your email taken off



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK &amp; win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&amp;url=/
_______________________________________________
NFS maillist  -  NFS-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please n</description>
    <dc:creator>Roman Dalton</dc:creator>
    <dc:date>2008-11-21T04:34:07</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23363">
    <title>[PATCH] SUNRPC: Fix a performance regression in the RPC authentication code</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23363</link>
    <description>Fix a regression reported by Max Kellermann whereby kernel profiling
showed that his clients were spending 45% of their time in
rpcauth_lookup_credcache.

It turns out that although his processes had identical uid/gid/groups,
generic_match() was failing to detect this, because the task-&gt;group_info
pointers were not shared. This again lead to the creation of a huge number
of identical credentials at the RPC layer.

The regression is fixed by comparing the contents of task-&gt;group_info
if the actual pointers are not identical.

Signed-off-by: Trond Myklebust &lt;Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt;
---

 net/sunrpc/auth_generic.c |   20 ++++++++++++++++++--
 1 files changed, 18 insertions(+), 2 deletions(-)


diff --git a/net/sunrpc/auth_generic.c b/net/sunrpc/auth_generic.c
index 744b79f..4028502 100644
--- a/net/sunrpc/auth_generic.c
+++ b/net/sunrpc/auth_generic.c
&lt; at &gt;&lt; at &gt; -133,13 +133,29 &lt; at &gt;&lt; at &gt; static int
 generic_match(struct auth_cred *acred, struct rpc_cred *cred, int flags)
 {
 struct generic_cr</description>
    <dc:creator>Trond Myklebust</dc:creator>
    <dc:date>2008-11-20T21:06:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23355">
    <title>nfs-utils, umount -l, and unmount requests</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23355</link>
    <description>[I hope this is the right place to send this.  I tried 
agud-H+wXaHxf7aLQT0dZR+AlfA&lt; at &gt;public.gmane.org, who is listed on the relevant file's copyright,
but that mailbox was disabled.]


This concerns nfsmount.c in nfs-utils-1.1.4.

I spent most of today trying to figure out why after upgrading an NFS
client machine from Mandriva 2007.1 to 2008.1 suddenly the NFS server
stopped logging  "authenticated unmount request" messages when the
client rebooted.  It turned out this was a consequence of the umount
"-l" flag, which is used in the shutdown scripts and the many recent
changes in the organization of the umount commands.  Long story short,
under Mandriva 2007.1 umount looked for umount.nfs, which was not
present in that release, and then went on to send the unmount request
itself.  On Mandriva 2008.1, where umount.nfs is present, the ball
was passed to this program, which promptly dropped it if "-l" had been
specified.  The NFS directory was unmounted correctly, but the "unmount
request" was never sent. 

I tr</description>
    <dc:creator>David Mathog</dc:creator>
    <dc:date>2008-11-19T23:54:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23353">
    <title>[PATCH] lockd: handle fl_grant callbacks with coalesced locks (RFC)</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23353</link>
    <description>Dave Teigland opened a bug stating that he was having some problems with
DLM and lockd. Essentially, the problem boiled down to the fact that
when you do a posix lock of a region that touches another lock, the VFS
will coalesce the locks and return a lock that encompasses the whole
range.

The problem here is that DLM then does a fl_grant callback to lockd with
the new coalesced lock. The fl_grant callback then looks through all
of the blocks and eventually returns -ENOENT since none match the
coalesced lock.

I'm having a very hard time tracking down info about how the fl_grant
callback is supposed to work. Is it OK to send an fl_grant callback
with a lock that's larger than the one requested? If so, then lockd
needs to account for that possibility. Also, what exactly is the
purpose of the second arg on fl_grant ("conf" in nlmsvc_grant_deferred)?

What follows is a patch that changes nlmsvc_grant_deferred to account
for the possibility that it may receive an fl_grant that has already
been coalesced. It chan</description>
    <dc:creator>Jeff Layton</dc:creator>
    <dc:date>2008-11-19T21:37:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfs/23352">
    <title>[PATCH 0/4] Support for IPv6 in the showmount command</title>
    <link>http://comments.gmane.org/gmane.linux.nfs/23352</link>
    <description>Hi Steve-

These patches implement support for rpcbind v3/v4 queries and IPv6 NFS
servers in the showmount command.  Please consider these for the next
release of nfs-utils.

Thanks!

---

Chuck Lever (4):
      showmount command: support querying IPv6 servers
      showmount command: move logic to acquire RPC client handle out of main()
      showmount command: Remove unused local getport() implementation
      showmount command: call nfs_getport instead of local getport


 utils/showmount/showmount.c |  237 +++++++++++++++++--------------------------
 1 files changed, 91 insertions(+), 146 deletions(-)

</description>
    <dc:creator>Chuck Lever</dc:creator>
    <dc:date>2008-11-18T19:29:28</dc:date>
  </item>
  <textinput about="http://search.gmane.org/?group=$group=gmane.linux.nfs">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.nfs</link>
  </textinput>
</rdf:RDF>
