VFS and tdb_lock

[Jeremy Allison]

Brad Sahr wrote:
> 
> When I run multiple SMB clients through my VFS, I get multiple smbd
> processes hanging in tdb_lock(). Sound familiar to anyone? I'm running with
> source from the head branch about 3 weeks ago.
> 
> I've also come across what I thought was an interesting use of a file's dev
> and ino fields - as unique keys used by tdb (if I follow correctly).
> 
> Here are two stack traces of two different smbd processes that demonstrate
> what I'm running into. Please let me know if there's anything else that I
> can supply for information. From the VFS perspective, the last thing it sees
> from Samba is a call to stat(). From the SMB client perspective, the SMB
> client app (MS Explorer) simply hangs. On the Samba box, I see the client
> start up a new smbd every minute or so - with each smbd ending up in the
> same situation.

Can you reproduce this without the use of your vfs ?

The stack trace here :

#1  0x8107dd8 in tdb_lock (tdb=0x817c878, list=86, locktype=0) at
tdb/tdb.c:128
#2  0x81088f9 in tdb_fetch (tdb=0x817c878, key={dptr = 0x816673c "\b\b",
      dsize = 12}) at tdb/tdb.c:695
#3  0x80ea73f in set_share_mode (fsp=0x81a6768, port=1074, op_type=3)
    at locking/locking.c:404
#4  0x8088e5b in open_file_shared (conn=0x819fbc0,
    fname=0xbffff8f8 "Never is Enough.mp3", share_mode=32832, ofun=1,
    mode=484, oplock_request=3, Access=0xbffff890, action=0xbffff894)
    at smbd/open.c:772
#5  0x8074c34 in reply_ntcreate_and_X (conn=0x819fbc0, inbuf=0x817dea1 "",
    outbuf=0x818e2a9 "", length=108, bufsize=65535) at smbd/nttrans.c:819
#6  0x808ef92 in switch_message (type=162, inbuf=0x817dea1 "",
    outbuf=0x818e2a9 "", size=108, bufsize=65535) at smbd/process.c:577
#7  0x808f050 in construct_reply (inbuf=0x817dea1 "", outbuf=0x818e2a9 "",
    size=108, bufsize=65535) at smbd/process.c:611
#8  0x808f1fe in process_smb (inbuf=0x817dea1 "", outbuf=0x818e2a9 "")
    at smbd/process.c:676
#9  0x808fa48 in smbd_process () at smbd/process.c:1063
#10 0x80627e8 in main (argc=1, argv=0xbffffe74) at smbd/server.c:764

shows the tdb code attempting to do an actual fcntl lock
call at line 128 in tdb/tdb.c

Now, in smbd/open.c at line 772 it's trying to do a set_share_mode()
call. For this to be correct, the tdb hashchain *SHOULD ALREADY BE LOCKED*
with a WRITE fcntl lock. ie. There should already be a lock on this hashchain
that the code in open_file_shared() obtained previously at either lines 664 or
693 in smbd/open.c (note the comments at line 665 and 706 in smbd/open.c).

So the tdb logic being used in this situation should be the "increment
existing lock count" logic at tdb/tdb.c:135, *not* the fcntl lock call
at tdb/tdb.c:128.

I'm not sure how this state can be acheived.......... more data
would be *very* useful here as I'm hoping you haven't uncovered
a logic bug introduced in the tdb rewrite....

Thanks,

	Jeremy Allison,
	Samba Team.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------