smbd panic at find_oplock_types().

[Hemanth Thummala]

Volker,
These are user files not internal/temp files. Yeah stat open checks for
non-zero access mask. But I have seen at one place where we send zero
access mask along NO_OPLOCK flag.

In create_file_unixpath():
...
/* Open the base file. */
status = create_file_unixpath(conn, NULL, smb_fname_base, 0==> Access mask,
      FILE_SHARE_READ
      | FILE_SHARE_WRITE
      | FILE_SHARE_DELETE,
      base_create_disposition,
      0, 0, 0==> oplock, 0, 0, NULL, NULL,
      &base_fsp, NULL);
TALLOC_FREE(smb_fname_base);
...

But this will happen only when the request comes for stream files. But I
feel we should mark access mask non-zero so that we can filter these shared
mode locks with is_stat_open().
In my case, file doesn't have any streams. So I am ruling this possibility
out. But thought of showing that we have a case where we are using zero
access mask for stat/internal opens.

Thanks,
Hemanth.




On Tue, Aug 5, 2014 at 1:53 AM, Volker Lendecke <Volker.Lendecke at sernet.de>
wrote:

> On Mon, Aug 04, 2014 at 03:42:55PM -0700, Hemanth Thummala wrote:
> > Hi,
> >
> > We are using samba 3.6.12+ stack. And we are hitting this smbd panic
> > customer site frequently(atleast once in a week). Couldn't reproduce this
> > issue in house but collected few details. This issue happens only with
> PDF
> > application files.
>
> Is this a user file or some internal print file? The
> access_mask=0 in the second share entry is really
> surprising. I could see a stat open not breaking the batch
> oplock, but that does have some access mask bits set. See
> is_stat_open(). Really weird.
>
> Volker
>