PR#21625: Smbd processes get stuck and consume 100% CPU.

[Fredrik Ohrn]

On Mon, 20 Aug 2001 jeremy at valinux.com wrote:

> I've jut checked some changes into HEAD and 2.2 CVS to address
> this problem. The first thing I did was to add a deliberate panic if
> an smbd is trying to break its own oplock and cannot find a reference
> to that file in its open file list. This will allow someone
> to use a debugger to catch this in the act (with an additional
> 'panic action' script).
>
> The second is a robustness fix that (theoretically) shouldn't
> be needed, that ensures that once an oplock break request
> has returned, that the record that caused this break to
> be triggered is removed by the requesting process (if it
> exists). The reason this shouldn't be neccessary is that
> the receiving process should be removing this record even
> if the client failed to respond to the break.
>
> If people experiencing the 'spin' problem could CVS update
> and test this change I'd appreciate it.
>

Ok,

I've just tried the 2.2 CVS version and everything went bezerk.

It spews this message in the log for each and every file that is opened:

[2001/08/21 11:24:30, 0, pid=28021] smbd/open.c:open_mode_check(540)
  open_mode_check: cannot delete entry when breaking oplock (3) on file eudora/eudora.ini, dev = 80015e, inode = 9702566

And all Windows apps that try to lock files fail with the message that
the file is already locked by another application.

I guess del_share_entry always return -1...


Regards,
Fredrik

-- 
   "It is easy to be blinded to the essential uselessness of computers by
   the sense of accomplishment you get from getting them to work at all."
                                                   - Douglas Adams

Fredrik Öhrn                               Chalmers University of Technology
ohrn at chl.chalmers.se                                                  Sweden