From owner-freebsd-fs@FreeBSD.ORG  Tue Jan 28 09:40:47 2014
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: fs@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id D75BC9A5;
 Tue, 28 Jan 2014 09:40:47 +0000 (UTC)
Received: from vlakno.cz (mail.vlakno.cz [95.129.96.251])
 by mx1.freebsd.org (Postfix) with ESMTP id 9AD411A6F;
 Tue, 28 Jan 2014 09:40:47 +0000 (UTC)
Received: by vlakno.cz (Postfix, from userid 1002)
 id EFE491CC559F; Tue, 28 Jan 2014 10:40:45 +0100 (CET)
Date: Tue, 28 Jan 2014 10:40:45 +0100
From: Roman Divacky <rdivacky@freebsd.org>
To: Bruce Evans <brde@optusnet.com.au>
Subject: Re: BUG: possible NULL pointer dereference in nfs server
Message-ID: <20140128094045.GB16311@freebsd.org>
References: <410866336.17211125.1390863857778.JavaMail.root@uoguelph.ca>
 <20140128112731.S1362@besplex.bde.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140128112731.S1362@besplex.bde.org>
User-Agent: Mutt/1.5.22 (2013-10-16)
Cc: Dimitry Andric <dim@FreeBSD.org>, fs@FreeBSD.org
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs/>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 09:40:47 -0000

> > Yea, so long as it includes a comment that states this is done to
> > work around a stupid compiler bug.
> 
> Ugh.
> 
> The above has the following bugs:
> - gross style bugs (lines longer than 80 characters)
> - large code to do nothing
> - would be even larger with a comment
> - cannot actually work around any compiler bug involving abort(), since it
>    has no effect on production kernels where KASSERT() is null.
> 
> >> It is present even in your setup :) Just "objdump -d kernel | grep
> >> ud2" on kernel compiled
> >> by clang.
> >>
> > I actually use gcc, but I believe you. I'll admit I still don't understand
> > why having a trap instruction that never gets executed is a bad thing?
> 
> It isn't but trying to link to the noexistent function abort() on
> arches that don't have any trap instruction is a bad thing.  According
> the above, this occurs on sparc64.  It must be a gcc bug, since sparc64
> doesn't have clang.  However, I couldn't get gcc on sparc64 to generate
> an abort() for *NULL.  Similarly on x86 (gcc is hard to test on x86,
> since it is broken (not installed) on FreeBSD cluster machines for

I was testing clang compiled kernel on sparc64. 

The problem is that there's nothing making sure that the NULL pointer
dereference doesnt happen. So if someone happens to call the function with
wrong flags it will crash.

Thats why I want to add the KASSERT, to catch possible future cases
when this happens.

Unfortunately our KASSERT is not an assert so to remove the actual
abort/trap/ud2 I have to remove the flag.


Ok?


Roman