headers
Payphone LIOU | 1 Sep 2008 05:53
Picon

mem leak?

Hi, linux-nfs :
			
  in nfs-utils1.1.3,  procedure "get_exportlist()" would malloc() some memory for storing the
directories and groups for "showmount". obviously those memory are not released when the procedure
ends. once mountd received a signal for quiting itself(eg : kill -9 `pidof mountd`), it will call
"killer()" for some exiting-works. but those memory allocated in "get_exportlist()" were not
released. memory leak? i am not sure. :-(

Payphone LIOU 

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Ricardo Santos | 1 Sep 2008 18:40
Picon
Favicon

Re: directory attribute cache on NFS4 client

I'm checking the NFS client code to understand it, and I saw this:

-- inode.c
int nfs_attribute_timeout(struct inode *inode)
{
        struct nfs_inode *nfsi = NFS_I(inode);

        if (nfs_have_delegation(inode, FMODE_READ))
                return 0;

--

So, if a inode has a delegation, will it never be timed out, until the
delegation been free, right ?

If the delegated inode has been deleted ?

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |
headers
Tom Tucker | 1 Sep 2008 19:20

Re: NFS regression? Odd delays and lockups accessing an NFS export.

Ian Campbell wrote:
> On Sun, 2008-08-31 at 14:51 -0500, Tom Tucker wrote:
>   
>> Looks like you ran this on the client. Sorry, Ian, I should have been
>> more specific. You need to modify the rpc_debug file on the server.
>>     
>
> I tried this on the server but it's pretty crippling (the server is
> quite weedy, 300MHz K3 or something).
>
> I'll leave it logging overnight since things should be pretty quiet (and
> that's often when the problem occurs) but if there's a less aggressive
> setting than 256 but which would still be useful I could leave it on
> permanently until the problem happens.
>
>   
Thanks Ian. Unfortunately, that's as fine grained as it gets. 256 
(0x100) is the bit for transport logging.
> Ian.
>   

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Ian Campbell | 1 Sep 2008 19:46
Picon

Re: NFS regression? Odd delays and lockups accessing an NFS export.

On Mon, 2008-09-01 at 12:20 -0500, Tom Tucker wrote:
> Thanks Ian. Unfortunately, that's as fine grained as it gets. 256 
> (0x100) is the bit for transport logging.

Doh, of course, I was thinking of 255...

No repro today. I'll let you know when I see something.

Ian.

--

-- 
Ian Campbell

History is nothing but a collection of fables and useless trifles,
cluttered up with a mass of unnecessary figures and proper names.
		-- Leo Tolstoy
Permalink | Reply | 0 comments |
headers
J. Bruce Fields | 1 Sep 2008 20:46

nfsd fixes for 2.6.27

The following nfsd bugfixes are available in for-2.6.27 branch at:

  git://linux-nfs.org/~bfields/linux.git for-2.6.27

--b.

Andy Adamson (1):
      nfsd: fix compound state allocation error handling

Cyrill Gorcunov (1):
      sunrpc: fix possible overrun on read of /proc/sys/sunrpc/transports

J. Bruce Fields (1):
      nfsd: fix buffer overrun decoding NFSv4 acl

Tom Tucker (1):
      svcrdma: Fix race between svc_rdma_recvfrom thread and the dto_tasklet

 fs/nfsd/nfs4acl.c                        |    2 +-
 fs/nfsd/nfs4proc.c                       |   12 ++++++------
 include/linux/sunrpc/svc_rdma.h          |    1 -
 net/sunrpc/sysctl.c                      |   18 ++++--------------
 net/sunrpc/xprtrdma/svc_rdma_recvfrom.c  |    8 ++++----
 net/sunrpc/xprtrdma/svc_rdma_transport.c |    5 ++---
 6 files changed, 17 insertions(+), 29 deletions(-)

diff --git a/fs/nfsd/nfs4acl.c b/fs/nfsd/nfs4acl.c
index b6ed383..54b8b41 100644
--- a/fs/nfsd/nfs4acl.c
+++ b/fs/nfsd/nfs4acl.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. Bruce Fields | 1 Sep 2008 20:51
Picon
Favicon

[PATCH] sunrpc: fix possible overrun on read of /proc/sys/sunrpc/transports

From: Cyrill Gorcunov <gorcunov@...>

Vegard Nossum reported
----------------------
> I noticed that something weird is going on with /proc/sys/sunrpc/transports.
> This file is generated in net/sunrpc/sysctl.c, function proc_do_xprt(). When
> I "cat" this file, I get the expected output:
>    $ cat /proc/sys/sunrpc/transports
>    tcp 1048576
>    udp 32768

> But I think that it does not check the length of the buffer supplied by
> userspace to read(). With my original program, I found that the stack was
> being overwritten by the characters above, even when the length given to
> read() was just 1.

David Wagner added (among other things) that copy_to_user could be
probably used here.

Ingo Oeser suggested to use simple_read_from_buffer() here.

The conclusion is that proc_do_xprt doesn't check for userside buffer
size indeed so fix this by using Ingo's suggestion.

Reported-by: Vegard Nossum <vegard.nossum@...>
Signed-off-by: Cyrill Gorcunov <gorcunov@...>
CC: Ingo Oeser <ioe-lkml@...>
Cc: Neil Brown <neilb@...>
Cc: Chuck Lever <chuck.lever@...>
Cc: Greg Banks <gnb@...>
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. Bruce Fields | 1 Sep 2008 20:51
Picon
Favicon

[PATCH] nfsd: fix buffer overrun decoding NFSv4 acl

The array we kmalloc() here is not large enough.

Thanks to Johann Dahm and David Richter for bug report and testing.

Signed-off-by: J. Bruce Fields <bfields@...>
Cc: David Richter <richterd@...>
Tested-by: Johann Dahm <jdahm@...>
---
 fs/nfsd/nfs4acl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/nfsd/nfs4acl.c b/fs/nfsd/nfs4acl.c
index b6ed383..54b8b41 100644
--- a/fs/nfsd/nfs4acl.c
+++ b/fs/nfsd/nfs4acl.c
 <at>  <at>  -443,7 +443,7  <at>  <at>  init_state(struct posix_acl_state *state, int cnt)
 	 * enough space for either:
 	 */
 	alloc = sizeof(struct posix_ace_state_array)
-		+ cnt*sizeof(struct posix_ace_state);
+		+ cnt*sizeof(struct posix_user_ace_state);
 	state->users = kzalloc(alloc, GFP_KERNEL);
 	if (!state->users)
 		return -ENOMEM;
--

-- 
1.5.5.rc1

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. Bruce Fields | 1 Sep 2008 23:20

Re: mem leak?

On Mon, Sep 01, 2008 at 11:53:07AM +0800, Payphone LIOU wrote:
> Hi, linux-nfs :
> 			
>   in nfs-utils1.1.3,  procedure "get_exportlist()" would malloc() some
>   memory for storing the directories and groups for "showmount".
>   obviously those memory are not released when the procedure ends.
>   once mountd received a signal for quiting itself(eg : kill -9 `pidof
>   mountd`), it will call "killer()" for some exiting-works. but those
>   memory allocated in "get_exportlist()" were not released. memory
>   leak? i am not sure. :-(

You're talking about the allocation done on this line?:

	e = (struct exportnode *) xmalloc(sizeof(*e));

From a quick glance, it looks like the code tries to free that up the
next time get_exportlist() is called, in that first loop over elist.  I
haven't tried to figure out whether that code's correct, though; maybe
you have?  Patches always welcome.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
J. Bruce Fields | 2 Sep 2008 19:50

Re: directory attribute cache on NFS4 client

On Mon, Sep 01, 2008 at 04:40:04PM +0000, Ricardo Santos wrote:
> I'm checking the NFS client code to understand it, and I saw this:
> 
> -- inode.c
> int nfs_attribute_timeout(struct inode *inode)
> {
>         struct nfs_inode *nfsi = NFS_I(inode);
> 
>         if (nfs_have_delegation(inode, FMODE_READ))
>                 return 0;
> 
> --
> 
> So, if a inode has a delegation, will it never be timed out, until the
> delegation been free, right ?
> 
> If the delegated inode has been deleted ?

The server should recall the delegation before allowing the delegated
file to be deleted.  (The current linux server is buggy--it doesn't do
that.  Patches are on the way soon, I hope....)

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 3 comments |
headers
Ricardo Santos | 2 Sep 2008 21:52
Picon
Favicon

Re: directory attribute cache on NFS4 client

Has anyway to disable delegations on Linux NFS Server ?

Thanks for help

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |

Gmane