VFS and tdb_lock

[Brad Sahr]

Jeremy,

I can't reproduce the problem when the VFS is not involved, and this is what
I expected.

I think that my VFS is doing something to cause the open/locking code to get
confused. My concern starts with the call to vfs_file_exist() at the start
of open_file_shared() in smbd/open.c. In my VFS, the file does not actually
exist on disk (yet) so I fill out the stat struct as best as I can - getting
some file information from a remote source. Eventually, the tdb locking code
uses the device and inode information within the stat struct to perform
locking. I'm assuming that these are being used as a means to have some
unique information for the lock - correct?

The locking code doesn't actually perform any file I/O? If it did, it should
come through my VFS.

What kind of 'more data' would you like?

Brad

> -----Original Message-----
> From: samba-technical-admin at us4.samba.org
> [mailto:samba-technical-admin at us4.samba.org]On Behalf Of Jeremy Allison
> Sent: Thursday, September 28, 2000 4:35 PM
> To: Brad Sahr
> Cc: Samba Technical List; jeremy at valinux.com
> Subject: Re: VFS and tdb_lock
>
>
> 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.
> --------------------------------------------------------
>