From: "Toralf Förster" <toralf.foerster@gmx.de>
To: "J. Bruce Fields" <bfields@fieldses.org>
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 18:20:42 +0100 [thread overview]
Message-ID: <51532A6A.4040307@gmx.de> (raw)
In-Reply-To: <20130326181717.GA8978@fieldses.org>
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).
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
next prev parent reply other threads:[~2013-03-27 17:20 UTC|newest]
Thread overview: 12+ 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-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 18:17 ` J. Bruce Fields
2013-03-27 17:20 ` Toralf Förster [this message]
2013-03-27 17:46 ` J. Bruce Fields
2013-03-27 21:35 ` Toralf Förster
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=51532A6A.4040307@gmx.de \
--to=toralf.foerster@gmx.de \
--cc=bfields@fieldses.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).