From owner-soc-status@FreeBSD.ORG Fri Jun 25 22:37:38 2010 Return-Path: Delivered-To: soc-status@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED017106566C for ; Fri, 25 Jun 2010 22:37:38 +0000 (UTC) (envelope-from gpf.kira@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 87EE08FC12 for ; Fri, 25 Jun 2010 22:37:38 +0000 (UTC) Received: by wyf22 with SMTP id 22so1774327wyf.13 for ; Fri, 25 Jun 2010 15:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=SEvKAaaQTUht1+WWrfEKdwiC/0tVdD6mwkRxRkkRbq8=; b=wHZJsZ5bowqyLMLx/CXRKSIB5O4IKzk72qqAOBcAMjKoTWD9RpLBudGztp9x8BCA6r Zfr9pZnnxne1JM94ewJNL7r8sIDiuD8P8hquesTKSk2t3qTqv2zl1TIlzTI5FCb4PVhS oPx8UDQfo14mGetNRtfiLnUCvox8k1Xo31oAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=j/rnNG8TQVs2FIH4O9CXIwYQkVHefDo+pdyjA0MYiyYGV9gvLNLGxqY3Gpv+hwfxBx zr2oooD+WCAE6hDR/wgglWpYiOI5Ihyn64R2Tl9hfmFD4WfBy4kCBbbqV3dnSUB4jxrB Y/LeezalaakI5YF8HRBEelqg+IpHdkEtv2krU= MIME-Version: 1.0 Received: by 10.216.86.3 with SMTP id v3mr5618538wee.12.1277505456295; Fri, 25 Jun 2010 15:37:36 -0700 (PDT) Received: by 10.216.49.11 with HTTP; Fri, 25 Jun 2010 15:37:36 -0700 (PDT) Date: Sat, 26 Jun 2010 01:37:36 +0300 Message-ID: From: Efstratios Karatzas To: soc-status@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Audit Kernel Events, weekly report #4 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 22:37:39 -0000 Hello, this is the long overdue weekly report. Last couple of weeks I kept busy with university exams so there wasn't much progress. My obligations will end pretty soon and I'll be able to focus on my gsoc project. new stuff: - Finished support for nfsv2&3 in the new experimental nfs server; everything seems to be working tip top. - Updated my wiki page. I've 'deleted' the milestones that are done and I changed the timeline because I'm still waiting for some feedback on my ideas for 'audit & multiple record handling', from my mentor. If anyone is interested, I've also included a link to a small demo of my code: contains a shell script that triggers most of the nfs rpcs & the audit log that is being produced. Please refer to the wiki page for more info http://wiki.freebsd.org/SOC2010EfstratiosKaratzas - Also, I figured out why and when vn_fullpath() kernel-panicked in my code, after applying my old patches. If this point is reached, while we 're holding an exclusive lock on the vnode, the system will kernel panic with a exhaustive->shared situation: http://fxr.watson.org/fxr/source/kern/vfs_cache.c#L1096 Triggering this kernel panic can be done easily -again, with my old patches- if we: start the nfs server, the client mounts a filesystem and gets valid file handles, the server reboots and the client requests some operation -> No hints in namecache, we resort to VOP_VPTOCNP() and try to lock the vnode, boom. My current code is immune to this bug because I make sure that no locks are held when the two vn_fullpath KPIs are called. I'm taking the time to write all this because I think that the man page should be updated to reflect this new possible bogus behavior. Since RELENG_8, VOP_VPTOCNP() is called from vn_fullpath code and vn_fullpath() itself is used quite a few times in the kernel and some times, the caller holds a lock to the vnode. http://www.freebsd.org/cgi/man.cgi?query=vn_fullpath I've already started reading up on NFSv4 and compound RPCs and over the next week, I'll be working towards providing audit support for NFSv4 in the new experimental nfs server. After this is done, just before midterm evaluations (I hope), I'll start working on my last remaining milestone: making Audit framework handle multiple simultaneous audit records per kernel thread. As always, any input is much appreciated. Ta ta -- Efstratios "GPF" Karatzas