diff options
| author | Andrew Tridgell <tridge@samba.org> | 1998-01-12 00:01:18 +0000 |
|---|---|---|
| committer | Andrew Tridgell <tridge@samba.org> | 1998-01-12 00:01:18 +0000 |
| commit | d72183bda7bcb2204ad0ac1c387bdbf09cbe44dd (patch) | |
| tree | 428195bcde9ffb64df59a35ca1a84e183167eef2 /source | |
| parent | a6471daa2fe5b2b45914f4a82bc4a8b84b2c6da0 (diff) | |
| download | samba-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')
| -rw-r--r-- | source/smbd/server.c | 5 |
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); } |