<?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 rdf:about="http://permalink.gmane.org/gmane.linux.nfs">
    <title>gmane.linux.nfs</title>
    <link>http://permalink.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://permalink.gmane.org/gmane.linux.nfs/56781"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56780"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56779"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56778"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56777"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56776"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56775"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56774"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56773"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56772"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56771"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56770"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56769"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56768"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56766"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56765"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56764"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56763"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56751"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.nfs/56749"/>
      </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://permalink.gmane.org/gmane.linux.nfs/56781">
    <title>Re: Is the code stateid_generation_after()in legal C?</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56781</link>
    <description>&lt;pre&gt;Jim Rees &amp;lt;rees-63aXycvo3TyHXe+LvDLADg&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote on 2013/05/17 18:50:38:
not

Right, the below test prog demonstrates the signed overflow problem in 
newer gcc's
#include &amp;lt;assert.h&amp;gt;

int foo(int a) {
  assert(a+100 &amp;gt; a);
  printf("%d %d\n",a+100,a);
  return a;
}

int main() {
  foo(100);
  foo(0x7fffffff);
}

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

&lt;/pre&gt;</description>
    <dc:creator>Joakim Tjernlund</dc:creator>
    <dc:date>2013-05-18T12:10:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56780">
    <title>Re: [PATCH v2] nfsd: avoid undefined signed overflow</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56780</link>
    <description>&lt;pre&gt;
Hmm, what is actually wrong with plain-old
----  snip  ----
static bool stateid_generation_after(stateid_t *a, stateid_t *b)
{
return a-&amp;gt;si_generation &amp;gt; b-&amp;gt;si_generation;
}
----  snip  ----
?

Kind regards,
Bernd
&lt;/pre&gt;</description>
    <dc:creator>Bernd Petrovitsch</dc:creator>
    <dc:date>2013-05-18T11:04:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56779">
    <title>Re: [PATCH v2] nfsd: avoid undefined signed overflow</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56779</link>
    <description>&lt;pre&gt;
  On Fri, May 17, 2013 at 05:33:00PM -0400, Jim Rees wrote:
  &amp;gt; In C, signed integer overflow results in undefined behavior, but unsigned
  &amp;gt; overflow wraps around. So do the subtraction first, then cast to signed.
  
  Thanks!  Applying for 3.11.
  
  (I wonder if it actually bites anyone in practice?  Are there common
  compilers or architectures where this makes a difference?  Even if so I
  suppose that many generations is probably unlikely enough not to make
  this worth backporting to stable branches.)

I tested on the architectures I have at my fingertips and it made no
difference. My guess is you might need a one's complement architecture. Of
course we'll never see wraparound in our lifetimes, so no sense backporting
this.

I actually used a one's complement machine many years ago, a CDC 6600. I
don't think linux has been ported to it.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA&amp;lt; at &amp;gt;public.gmane.org
More majordomo i&lt;/pre&gt;</description>
    <dc:creator>Jim Rees</dc:creator>
    <dc:date>2013-05-17T22:30:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56778">
    <title>Re: [PATCH v2] nfsd: avoid undefined signed overflow</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56778</link>
    <description>&lt;pre&gt;
Thanks!  Applying for 3.11.

(I wonder if it actually bites anyone in practice?  Are there common
compilers or architectures where this makes a difference?  Even if so I
suppose that many generations is probably unlikely enough not to make
this worth backporting to stable branches.)

--b.

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

&lt;/pre&gt;</description>
    <dc:creator>Bruce Fields</dc:creator>
    <dc:date>2013-05-17T21:40:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56777">
    <title>[PATCH v2] nfsd: avoid undefined signed overflow</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56777</link>
    <description>&lt;pre&gt;In C, signed integer overflow results in undefined behavior, but unsigned
overflow wraps around. So do the subtraction first, then cast to signed.

Suggested-by: Joakim Tjernlund &amp;lt;joakim.tjernlund-SNLAxHN9vbcOP4wsBPIw7w&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
Signed-off-by: Jim Rees &amp;lt;rees-63aXycvo3TyHXe+LvDLADg&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
---
 fs/nfsd/nfs4state.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 316ec84..9850329 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -3427,7 +3427,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; grace_disallows_io(struct net *net, struct inode *inode)
 /* Returns true iff a is later than b: */
 static bool stateid_generation_after(stateid_t *a, stateid_t *b)
 {
-return (s32)a-&amp;gt;si_generation - (s32)b-&amp;gt;si_generation &amp;gt; 0;
+return (s32)(a-&amp;gt;si_generation - b-&amp;gt;si_generation) &amp;gt; 0;
 }
 
 static __be32 check_stateid_generation(stateid_t *in, stateid_t *ref, bool has_session)
&lt;/pre&gt;</description>
    <dc:creator>Jim Rees</dc:creator>
    <dc:date>2013-05-17T21:33:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56776">
    <title>[PATCH] nfsd: avoid undefined signed overflow</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56776</link>
    <description>&lt;pre&gt;In C, signed integer overflow results in undefined behavior, but unsigned
overflow wraps around. So do the subtraction first, then cast to signed.

Signed-off-by: Jim Rees &amp;lt;rees-63aXycvo3TyHXe+LvDLADg&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
---
 fs/nfsd/nfs4state.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 316ec84..9850329 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -3427,7 +3427,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; grace_disallows_io(struct net *net, struct inode *inode)
 /* Returns true iff a is later than b: */
 static bool stateid_generation_after(stateid_t *a, stateid_t *b)
 {
-return (s32)a-&amp;gt;si_generation - (s32)b-&amp;gt;si_generation &amp;gt; 0;
+return (s32)(a-&amp;gt;si_generation - b-&amp;gt;si_generation) &amp;gt; 0;
 }
 
 static __be32 check_stateid_generation(stateid_t *in, stateid_t *ref, bool has_session)
&lt;/pre&gt;</description>
    <dc:creator>Jim Rees</dc:creator>
    <dc:date>2013-05-17T20:16:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56775">
    <title>Re: [PATCH 2/3] SUNRPC: Faster detection if gssd is actually running</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56775</link>
    <description>&lt;pre&gt;
The timeout has to be non-zero, otherwise if you _do_ restart rpc.gssd,
it needs a certain time to actually connect to one of the gssd
rpc_pipes.

The 15 second initial timeout is there in order to deal with the fact
that it may take a moment or 2 for init to get round to starting
rpc.gssd. I didn't want to change that value right now.



&lt;/pre&gt;</description>
    <dc:creator>Myklebust, Trond</dc:creator>
    <dc:date>2013-05-17T17:52:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56774">
    <title>Re: [PATCH 3/3] SUNRPC: Convert auth_gss pipe detection to work in namespaces</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56774</link>
    <description>&lt;pre&gt;
Possibly, however given that we're still seeing distros using the binary
mount interface that was replaced 6 years ago...

&lt;/pre&gt;</description>
    <dc:creator>Myklebust, Trond</dc:creator>
    <dc:date>2013-05-17T17:55:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56773">
    <title>Re: Is the code stateid_generation_after()in legal C?</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56773</link>
    <description>&lt;pre&gt;
  static bool stateid_generation_after(stateid_t *a, stateid_t *b)
  {
          return (s32)a-&amp;gt;si_generation - (s32)b-&amp;gt;si_generation &amp;gt; 0;
  }
  
  overflow is undefined for signed integers and gcc uses that nowadays.
  Not sure if that can affect the above code?

I guess the intent there is to account for stateid wraparound. But it's not
clear to me this is doing the right thing. I think C specifies overflow
behavior for unsigned but not signed. So shouldn't it be something more like
this?

    (s32)(a-&amp;gt;si_generation - b-&amp;gt;si_generation) &amp;gt; 0

Either way, this probably deserves a comment.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA&amp;lt; at &amp;gt;public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Jim Rees</dc:creator>
    <dc:date>2013-05-17T16:50:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56772">
    <title>Is the code stateid_generation_after()in legal C?</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56772</link>
    <description>&lt;pre&gt;static bool stateid_generation_after(stateid_t *a, stateid_t *b)
{
        return (s32)a-&amp;gt;si_generation - (s32)b-&amp;gt;si_generation &amp;gt; 0;
}

overflow is undefined for signed integers and gcc uses that nowadays.
Not sure if that can affect the above code?

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

&lt;/pre&gt;</description>
    <dc:creator>Joakim Tjernlund</dc:creator>
    <dc:date>2013-05-17T14:38:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56771">
    <title>Re: Where in the server code is fsinfo rtpref calculated?</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56771</link>
    <description>&lt;pre&gt;
Maybe.  In any case I'd want to see data before changing our defaults.


Do you have a performance problem that you've actually measured, and if
so could you share the details?


I'm not terribly familiar with the client logic, but would expect this
to vary depending on kernel version, read-ahead policy, application
behavior and a number of other factors, so I'd recommend testing with
your workload and finding out.

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

&lt;/pre&gt;</description>
    <dc:creator>J. Bruce Fields</dc:creator>
    <dc:date>2013-05-17T13:56:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56770">
    <title>Re: NFS loop on 3.4.39</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56770</link>
    <description>&lt;pre&gt;Back on this old problem now with some more input. Upgraded my client to 
3.8.13(server is  on 3.4.44)
and got the NFS4ERR_OLD_STATEID ping pong effect.
Firefox was locked with process state "Dl" and I got this dmesg:

INFO: task mozStorage #2:6355 blocked for more than 120 seconds.
"echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
mozStorage #2   D f5619280     0  6355      1 0x00000000
 f446d440 00000086 f446d65c f5619280 f3745300 f5619280 ef0da810 c17e4280
 f3745300 c15a897e c17e4280 c17e4280 ef0da810 c17e4280 ef0da810 c17e4280
 f3745300 f3745300 c17e4280 c17e4280 ef0da810 c17e4280 f46124f8 f46124f8
Call Trace:
 [&amp;lt;c15a897e&amp;gt;] ? __schedule+0x23e/0x660
 [&amp;lt;c1088d70&amp;gt;] ? ktime_get_ts+0xf0/0x120
 [&amp;lt;c15a907e&amp;gt;] ? io_schedule+0x6e/0xb0
 [&amp;lt;c10c35f5&amp;gt;] ? sleep_on_page+0x5/0x10
 [&amp;lt;c15a75b5&amp;gt;] ? __wait_on_bit+0x45/0x70
 [&amp;lt;c10c35f0&amp;gt;] ? __lock_page+0x80/0x80
 [&amp;lt;c10c383d&amp;gt;] ? wait_on_page_bit+0x8d/0xa0
 [&amp;lt;c106ec10&amp;gt;] ? autoremove_wake_function+0x40/0x40
 [&amp;lt;c10c3a7c&amp;gt;] ? grab_cache_page_write_begin+0x9c/&lt;/pre&gt;</description>
    <dc:creator>Joakim Tjernlund</dc:creator>
    <dc:date>2013-05-17T13:18:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56769">
    <title>Re: Where in the server code is fsinfo rtpref calculated?</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56769</link>
    <description>&lt;pre&gt;
Possibly. But we have no control over that (the application read size,
I mean).


No. But 32x 32k reads is reasonable (because it gives other RPCs a
look-in). I'm focused on reads because it makes up the majority of
our NFS traffic. I'm concerned because as it stands (out of the box)
if the majority of our n knfsd threads are waiting for a 1MB read to
return then no other RPC request will be serviced and will just
contribute to the backlog. This backlog itself will probably also contain
a hefty no. of 1MB read requests too. In short, a lot of other RPC calls
that are not reads will just be blocking and this will appear to an end
user as poor performance.

We deal with a great number of fairly large files - 10s of GBs in size. We just
don't want others to suffer because of large request sizes coming in (writes
end up being of the same size too but there are less of them). Our use cases are
varied but they all have to share the same resource (the array of NFS servers).

We've only really seen this since our u&lt;/pre&gt;</description>
    <dc:creator>James Vanns</dc:creator>
    <dc:date>2013-05-17T11:43:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56768">
    <title>Re: [PATCH 2/3] SUNRPC: Faster detection if gssd is actually running</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56768</link>
    <description>&lt;pre&gt;
Chuck points out I'm confused, it's actually 15s then 1/4s (why 1/4s?).

(Apologies, somehow I saw a "&amp;gt;&amp;gt; 2" in there and my brain shut down and
jumped to the "exponential delay" conclusion.)

Still sort of curious how we're choosing these delays, though.

Hard to imagine people won't still notice the delay on first mount.
Given there's a workaround (run gssd), maybe that's just good enough for
now, I don't know.

--b.


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

&lt;/pre&gt;</description>
    <dc:creator>J. Bruce Fields</dc:creator>
    <dc:date>2013-05-17T01:03:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56766">
    <title>[PATCH] clnt_vc_control: fix VERS/PROG size</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56766</link>
    <description>&lt;pre&gt;Following commit converted some operations to use memcpy, but the size
of copied areas is now u_long, previously it was u_int32_t:
  commit fac3eb51c7055055bdd7dccd9db556d9e4a1cf35
  Author: Steve Dickson &amp;lt;steved-H+wXaHxf7aLQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
  Date:   Tue Feb 12 14:26:31 2013 -0500
      clnt_vc_control: Removed a strict-aliasing warning

This broke mount on ppc64/s390x:
  # ./mount.nfs -vvv -onfsvers=3,tcp rhel6-nfs:/export/home /mnt/test
  mount.nfs: timeout set for Fri May  3 15:20:14 2013
  mount.nfs: trying text-based options 'nfsvers=3,tcp,addr=10.1.1.5'
  mount.nfs: prog 100003, trying vers=3, prot=6
  mount.nfs: portmap query failed: RPC: Program/version mismatch
  mount.nfs: Protocol not supported

Signed-off-by: Jan Stancek &amp;lt;jstancek-H+wXaHxf7aLQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
---
 src/clnt_vc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/clnt_vc.c b/src/clnt_vc.c
index 7769809..2eab9e4 100644
--- a/src/clnt_vc.c
+++ b/src/clnt_vc.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -505,7 +505,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; cln&lt;/pre&gt;</description>
    <dc:creator>Jan Stancek</dc:creator>
    <dc:date>2013-05-16T20:25:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56765">
    <title>Re: [PATCH 0/3] Speed up detection of whether or not rpc.gssd is running</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56765</link>
    <description>&lt;pre&gt;
I don't understand what you're referring to--could you elaborate?

--b.

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

&lt;/pre&gt;</description>
    <dc:creator>J. Bruce Fields</dc:creator>
    <dc:date>2013-05-16T20:22:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56764">
    <title>Re: [PATCH 3/3] SUNRPC: Convert auth_gss pipe detection to work in namespaces</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56764</link>
    <description>&lt;pre&gt;
Might be worth deprecating the "legacy" version--add a warning in for
any users and then remove it if we don't see any evidence anyone's hit
it recently.

--b.

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

&lt;/pre&gt;</description>
    <dc:creator>J. Bruce Fields</dc:creator>
    <dc:date>2013-05-16T20:21:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56763">
    <title>Re: [PATCH 2/3] SUNRPC: Faster detection if gssd is actually running</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56763</link>
    <description>&lt;pre&gt;
So it's still a 15 second delay on the first mount, then 7 on the
second, then 3, 1, and no delay thereafter.  Is that right?

Why not be harsher and go straight to 0 after the first failure?

--b.

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

&lt;/pre&gt;</description>
    <dc:creator>J. Bruce Fields</dc:creator>
    <dc:date>2013-05-16T20:19:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56751">
    <title>[PATCH 02/13] Security: Add Hook to test if the particular xattr is part of a MAC model.</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56751</link>
    <description>&lt;pre&gt;From: David Quigley &amp;lt;dpquigl-a7DkhOHRHBuN9aS15agKxg&amp;lt; at &amp;gt;public.gmane.org&amp;gt;

The interface to request security labels from user space is the xattr
interface. When requesting the security label from an NFS server it is
important to make sure the requested xattr actually is a MAC label. This allows
us to make sure that we get the desired semantics from the attribute instead of
something else such as capabilities or a time based LSM.

Acked-by: James Morris &amp;lt;james.l.morris-QHcLZuEGTsvQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
Signed-off-by: Matthew N. Dodd &amp;lt;Matthew.Dodd-DABiIiYg7OfQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
Signed-off-by: Miguel Rodel Felipe &amp;lt;Rodel_FM-geVtEqcQUv4Eyxwt80+Gtti2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
Signed-off-by: Phua Eu Gene &amp;lt;PHUA_Eu_Gene-geVtEqcQUv4Eyxwt80+Gtti2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
Signed-off-by: Khin Mi Mi Aung &amp;lt;Mi_Mi_AUNG-geVtEqcQUv4Eyxwt80+Gtti2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
---
 include/linux/security.h   | 14 ++++++++++++++
 security/capability.c      |  6 ++++++
 security/security.c        |  6 ++++++
 security/se&lt;/pre&gt;</description>
    <dc:creator>Steve Dickson</dc:creator>
    <dc:date>2013-05-16T15:56:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56749">
    <title>Froe e71bf1d708e1294b3bae64d04f03228b3625f2a3 Mon Sep 17 00:00:00 2001</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56749</link>
    <description>&lt;pre&gt;This is an updated to the linux-3-10.rc1 release. The minor 
changes in this release are:

* Added the needed Acked-by:

* Stop labels leaking into the cache_consistency_bitmask

David Quigley (7):
  Security: Add Hook to test if the particular xattr is part of a MAC
    model.
  LSM: Add flags field to security_sb_set_mnt_opts for in kernel mount
    data.
  SELinux: Add new labeling type native labels
  NFSv4: Add label recommended attribute and NFSv4 flags
  NFSv4: Introduce new label structure
  NFSv4: Extend fattr bitmaps to support all 3 words
  NFS: Extend NFS xattr handlers to accept the security namespace

Steve Dickson (6):
  Security: Add hook to calculate context based on a negative dentry.
  NFSv4.2: Added NFS v4.2 support to the NFS client
  NFS:Add labels to client function prototypes
  NFS: Add label lifecycle management
  NFS: Client implementation of Labeled-NFS
  Kconfig: Add Kconfig entry for Labeled NFS V4 client

 fs/nfs/Kconfig                      |  28 ++
 fs/nfs/callback.c          &lt;/pre&gt;</description>
    <dc:creator>Steve Dickson</dc:creator>
    <dc:date>2013-05-16T15:56:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.nfs/56748">
    <title>Re: [PATCH 0/3] Speed up detection of whether or not rpc.gssd is running</title>
    <link>http://permalink.gmane.org/gmane.linux.nfs/56748</link>
    <description>&lt;pre&gt;
On May 15, 2013, at 3:50 PM, Trond Myklebust &amp;lt;Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:


Obviously my preference is to keep the existing krb5i -&amp;gt; sys logic and to try to address the upcall timeout, so this is a good direction, IMO.

After some review, I'm still a little concerned about initialization races inappropriately preventing upcalls, but time (and testing) will tell.  I'm happy with this solution if you and Bruce are.

Speaking of testing, I can test this series if you think that would be valuable, but I assume that those who originally reported the timeout problem (Jeff and Steve) should be the ones to confirm whether this series addresses their concern.



&lt;/pre&gt;</description>
    <dc:creator>Chuck Lever</dc:creator>
    <dc:date>2013-05-16T13:55:21</dc:date>
  </item>
  <textinput rdf: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>
