summaryrefslogtreecommitdiffstats
path: root/source/smbd/server.c
diff options
context:
space:
mode:
authorAndrew Tridgell <tridge@samba.org>1998-01-12 00:01:18 +0000
committerAndrew Tridgell <tridge@samba.org>1998-01-12 00:01:18 +0000
commitd72183bda7bcb2204ad0ac1c387bdbf09cbe44dd (patch)
tree428195bcde9ffb64df59a35ca1a84e183167eef2 /source/smbd/server.c
parenta6471daa2fe5b2b45914f4a82bc4a8b84b2c6da0 (diff)
downloadsamba-d72183bda7bcb2204ad0ac1c387bdbf09cbe44dd.tar.gz
samba-d72183bda7bcb2204ad0ac1c387bdbf09cbe44dd.tar.xz
samba-d72183bda7bcb2204ad0ac1c387bdbf09cbe44dd.zip
(applying fix to 1.9.18 as well)
I've now found the real oplock bug (the nasty one that I'm sure has been pestering us for a long time) The problem is that find_free_file() doesn't reserve the file. This means that during a recursive oplock break in an open you can get two files opened with the same fnum (yikes!). The 2nd open wipes out the oplock info in the Files[] structure (among other things) which totally screws the oplock breaks. This fix that I am applying now is a "quick fix". It will fail if the Files[] table is full and maybe under other conditions. It isn't really a fix at all, but it will "fix" the problem under most conditions and will also speed things up a little so I'm applying it anyway. I'll see if I can do a proper fix soon.
Diffstat (limited to 'source/smbd/server.c')
-rw-r--r--source/smbd/server.c5
1 files changed, 5 insertions, 0 deletions
diff --git a/source/smbd/server.c b/source/smbd/server.c
index b7ac241ff41..82e163fadd4 100644
--- a/source/smbd/server.c
+++ b/source/smbd/server.c
@@ -3671,9 +3671,13 @@ int find_free_file(void )
if (first_file == 0) first_file = 1;
}
+ if (first_file == MAX_OPEN_FILES)
+ first_file = 0;
+
for (i=first_file;i<MAX_OPEN_FILES;i++)
if (!Files[i].open) {
memset(&Files[i], 0, sizeof(Files[i]));
+ first_file++;
return(i);
}
@@ -3681,6 +3685,7 @@ int find_free_file(void )
for (i=1;i<first_file;i++)
if (!Files[i].open) {
memset(&Files[i], 0, sizeof(Files[i]));
+ first_file++;
return(i);
}