From owner-freebsd-fs@FreeBSD.ORG Sun Nov 2 17:53:29 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 438FC1065693; Sun, 2 Nov 2008 17:53:29 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 3F47E8FC1F; Sun, 2 Nov 2008 17:53:27 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1757078fgb.35 for ; Sun, 02 Nov 2008 09:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=7XyW/KnpcXkLJ0hL7US7oXjKvf5F9PDjfzskb0rbiYQ=; b=AMRFkcTRrYt/IO90t5p/JXyq6SoET57EbUYzKzdK3TZhM+xswCLg36j1trmjlc/ZmA D1nPxVYuAxl5UL7CcWMHR3BdN+LeJzMWiq0reZ0eoz619afzNObewT5zCeCA/QY+T34K ls2kmW5k5w47vlTZqNXH81uPTgsWOUYEC9dB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=xrLhQ2LWnk3TATlKDLbbxq5WslZTx/LgdSBnu0Rdgz1SAPgUKgEmQwLJ/MyU7Lw/qv x+w9xgK+4EpT5iV/YTvwq8FP3ZOBQJWL9JjaWu/REOXNMdVhBdnqHx73Piukn6x2xrWn T0nxNJ+DiT1VlRtk0NnwsNZu/D59sVBVbrMqQ= Received: by 10.86.66.19 with SMTP id o19mr10178116fga.18.1225648405145; Sun, 02 Nov 2008 09:53:25 -0800 (PST) Received: by 10.86.78.14 with HTTP; Sun, 2 Nov 2008 09:53:25 -0800 (PST) Message-ID: <3bbf2fe10811020953l29f1a7eesa4f4eeb49f0a2eba@mail.gmail.com> Date: Sun, 2 Nov 2008 18:53:25 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Yuri Pankov" In-Reply-To: <20081102163307.GB1434@darklight.homeunix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081102123100.GA1434@darklight.homeunix.org> <3bbf2fe10811020737g211dfb3fs54b48e4071db2393@mail.gmail.com> <3bbf2fe10811020817g1409a38ep26c1ee8edf075201@mail.gmail.com> <20081102163307.GB1434@darklight.homeunix.org> X-Google-Sender-Auth: 5dc9fe2f9ed1fc7a Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: reproducible panic with mount_smbfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2008 17:53:29 -0000 2008/11/2, Yuri Pankov : > On Sun, Nov 02, 2008 at 05:17:18PM +0100, Attilio Rao wrote: > > 2008/11/2, Attilio Rao : > > > 2008/11/2, Yuri Pankov : > > > > > > > Hi, > > > > > > > > Trying to mount nonexistent smb share with mount_smbfs leads to > > > > following panic: > > > > > > > > # mount_smbfs //yuri@lifebane/blahblah /mnt > > > > > > > > Unread portion of the kernel message buffer: > > > > smb_co_lock: recursive lock for object 1 > > > > panic: Lock (lockmgr) smb_vc not locked @ > > > > /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:329. > > > > cpuid = 0 > > > > KDB: stack backtrace: > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > > panic() at panic+0x182 > > > > witness_assert() at witness_assert+0x21a > > > > __lockmgr_args() at __lockmgr_args+0x17a > > > > smb_co_put() at smb_co_put+0x76 > > > > smb_sm_lookup() at smb_sm_lookup+0xfe > > > > smb_usr_lookup() at smb_usr_lookup+0xcd > > > > nsmb_dev_ioctl() at nsmb_dev_ioctl+0x1f6 > > > > giant_ioctl() at giant_ioctl+0x75 > > > > devfs_ioctl_f() at devfs_ioctl_f+0x76 > > > > kern_ioctl() at kern_ioctl+0x92 > > > > ioctl() at ioctl+0xfd > > > > syscall() at syscall+0x1bf > > > > Xfast_syscall() at Xfast_syscall+0xab > > > > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800939aec, rsp = > > > > 0x7fffffffe038, rbp = 0x7fffffffe450 --- > > > > Uptime: 6m46s > > > > Physical memory: 2032 MB > > > > > > > > > So, what is happening here is that smb_co_lock() is AFU. > > > Infact looking at the code: > > > int > > > smb_co_lock(struct smb_connobj *cp, int flags, struct thread *td) > > > { > > > ... > > > if (smb_co_lockstatus(cp, td) == LK_EXCLUSIVE && > > > (flags & LK_CANRECURSE) == 0) { > > > SMBERROR("recursive lock for object %d\n", cp->co_level); > > > return 0; > > > } > > > ... > > > > Yuri, > > could you please test this fix: > > http://www.freebsd.org/~attilio/netsmb.diff > > > > and report if it works? > > You could get a KASSERT running but this is expected as I want to > > identify on the callers who passes a malformed request and fix it. > > > > Thanks, > > Attilio > > > > > > -- > > Peace can only be achieved by understanding - A. Einstein > > > Thanks, Attilio. > > With this patch system doesn't panic anymore with nonexistent share > names (though I had to comment out smb_co_lockstatus prototype and > function to get rid of -Werror complaints). Still getting a LOR: > > netsmb_dev: loaded > lock order reversal: > 1st 0xffffff0021644008 smb_vc (smb_vc) @ > /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:332 > 2nd 0xffffffff81037368 smbsm (smbsm) @ > /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:348 > > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > __lockmgr_args() at __lockmgr_args+0xc2a > smb_co_lock() at smb_co_lock+0x38 > smb_co_gone() at smb_co_gone+0x38 > > smb_sm_lookup() at smb_sm_lookup+0xfe > smb_usr_lookup() at smb_usr_lookup+0xcd > nsmb_dev_ioctl() at nsmb_dev_ioctl+0x1f6 > giant_ioctl() at giant_ioctl+0x75 > devfs_ioctl_f() at devfs_ioctl_f+0x76 > kern_ioctl() at kern_ioctl+0x92 > ioctl() at ioctl+0xfd > syscall() at syscall+0x1bf > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800939aec, rsp = > > 0x7fffffffe048, rbp = 0x7fffffffe460 --- I've updated the patch in order to fix smb_co_lockstatus problem. Could you please stress test it while I investigate the LOR problem? Are you running with INVARIANTS? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein