From patchwork Tue Mar 26 18:17:17 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "J. Bruce Fields" X-Patchwork-Id: 2343321 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id E6F86DF264 for ; Tue, 26 Mar 2013 18:17:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753427Ab3CZSRT (ORCPT ); Tue, 26 Mar 2013 14:17:19 -0400 Received: from fieldses.org ([174.143.236.118]:47983 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751513Ab3CZSRR (ORCPT ); Tue, 26 Mar 2013 14:17:17 -0400 Received: from bfields by fieldses.org with local (Exim 4.76) (envelope-from ) id 1UKYQv-0002ao-D3; Tue, 26 Mar 2013 14:17:17 -0400 Date: Tue, 26 Mar 2013 14:17:17 -0400 From: "J. Bruce Fields" To: Toralf =?utf-8?Q?F=C3=B6rster?= Cc: Linux NFS mailing list , Linux Kernel Subject: Re: kernel 3.8.4 : kernel BUG at fs/locks.c:2093! part #2 Message-ID: <20130326181717.GA8978@fieldses.org> References: <514F31AF.3080709@gmx.de> <20130325220143.GD10887@fieldses.org> <20130326144640.GB3353@fieldses.org> <5151DEF7.3060003@gmx.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5151DEF7.3060003@gmx.de> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Tue, Mar 26, 2013 at 06:46:31PM +0100, Toralf Förster wrote: > On 03/26/2013 03:46 PM, J. Bruce Fields wrote: > > Can you run with test patches? > > > > This just makes nfsd's fput calls synchronous so that we see in the > > backtrace who called them. > > Well - the patched 3.8.4 host kernel now survives the stress test of the UML system. 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: [] __kmalloc+0x1b9/0x1e0 > 2013-03-26T18:32:17.487+01:00 n22 kernel: [] ? cache_check+0x22f/0x340 [sunrpc] > 2013-03-26T18:32:17.487+01:00 n22 kernel: [] nfs4_acl_new+0x1c/0x30 [nfsd] > 2013-03-26T18:32:17.488+01:00 n22 kernel: [] 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 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 Signed-off-by: J. Bruce Fields --- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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;