All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Toralf Förster" <toralf.foerster@gmx.de>
Cc: Linux NFS mailing list <linux-nfs@vger.kernel.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: kernel 3.8.4 : kernel BUG at fs/locks.c:2093!   part #2
Date: Wed, 27 Mar 2013 13:46:25 -0400	[thread overview]
Message-ID: <20130327174625.GA27426@fieldses.org> (raw)
In-Reply-To: <51532A6A.4040307@gmx.de>

On Wed, Mar 27, 2013 at 06:20:42PM +0100, Toralf Förster wrote:
> On 03/26/2013 07:17 PM, J. Bruce Fields wrote:
> > 
> > Bah, too bad.  That patch was definitely not a fix, so there may be some
> > race here.
> > 
> >> What I get at the host is now :
> >>
> >> 2013-03-26T18:32:17.487+01:00 n22 kernel: ------------[ cut here ]------------
> >> 2013-03-26T18:32:17.487+01:00 n22 kernel: WARNING: at mm/page_alloc.c:2376 __alloc_pages_nodemask+0x262/0x7c0()
> > ...
> >> 2013-03-26T18:32:17.487+01:00 n22 kernel: [<c110f149>] __kmalloc+0x1b9/0x1e0
> >> 2013-03-26T18:32:17.487+01:00 n22 kernel: [<f85835bf>] ? cache_check+0x22f/0x340 [sunrpc]
> >> 2013-03-26T18:32:17.487+01:00 n22 kernel: [<f90a0b1c>] nfs4_acl_new+0x1c/0x30 [nfsd]
> >> 2013-03-26T18:32:17.488+01:00 n22 kernel: [<f9095482>] nfsd4_decode_fattr+0x302/0x6c0 [nfsd]
> > ...
> > 
> > A different bug, but thanks for catching it, I suspect the following is
> > all we need.
> > 
> > --b.
> > 
> > commit 814d9d4f9164c3d778dadd093a54bb55d9a0c576
> > Author: J. Bruce Fields <bfields@redhat.com>
> > Date:   Tue Mar 26 14:11:13 2013 -0400
> > 
> >     nfsd4: reject "negative" acl lengths
> >     
> >     Since we only enforce an upper bound, not a lower bound, a "negative"
> >     length can get through here.
> >     
> >     The symptom seen was a warning when we attempt to a kmalloc with an
> >     excessive size.
> >     
> >     Reported-by: Toralf Förster <toralf.foerster@gmx.de>
> >     Signed-off-by: J. Bruce Fields <bfields@redhat.com>
> > 
> > diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
> > index 0dc1158..d1dd710 100644
> > --- a/fs/nfsd/nfs4xdr.c
> > +++ b/fs/nfsd/nfs4xdr.c
> > @@ -264,7 +264,7 @@ nfsd4_decode_fattr(struct nfsd4_compoundargs *argp, u32 *bmval,
> >  		iattr->ia_valid |= ATTR_SIZE;
> >  	}
> >  	if (bmval[0] & FATTR4_WORD0_ACL) {
> > -		int nace;
> > +		u32 nace;
> >  		struct nfs4_ace *ace;
> >  
> >  		READ_BUF(4); len += 4;
> > 
> 
> I applied that patach on top of 3.8.4 and wonders now, whether the
> following is the consequence :
> 
> $ df -m /tmp/forT/victims/
> Filesystem     1M-blocks  Used Available Use% Mounted on
> /dev/sdb3         183851 34907    139599  21% /
> 
> $ sudo ls -lh --color /tmp/forT/victims/f062
> ---xr-S--T 2 tfoerste users 985G Mar 27 18:15 /tmp/forT/victims/f062
> 
> ls shows a 1 TB file within a partition where just 34 MB are used at all
> (its only one partition in that system and a separate small /boot too).

It's completely normal for a large file to only take up a small amount
of space, if the file is sparse.  Is that what you're asking about?

Otherwise, are you seeing any problems or any backtraces in the logs?

--b.

  reply	other threads:[~2013-03-27 17:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-24 17:02 kernel 3.8.4 : kernel BUG at fs/locks.c:2093! part #2 Toralf Förster
2013-03-24 17:02 ` Toralf Förster
2013-03-25 22:01 ` J. Bruce Fields
2013-03-25 22:01   ` J. Bruce Fields
2013-03-26 14:46   ` J. Bruce Fields
2013-03-26 17:37     ` Al Viro
2013-03-26 17:46     ` Toralf Förster
2013-03-26 17:46       ` Toralf Förster
2013-03-26 18:17       ` J. Bruce Fields
2013-03-27 17:20         ` Toralf Förster
2013-03-27 17:46           ` J. Bruce Fields [this message]
2013-03-27 21:35     ` Toralf Förster
2013-03-27 21:35       ` Toralf Förster
2013-03-27 21:57       ` J. Bruce Fields
2013-03-27 21:57         ` J. Bruce Fields
2013-03-29 18:43         ` J. Bruce Fields
2013-04-01 20:26           ` Toralf Förster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130327174625.GA27426@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=toralf.foerster@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.