smbd panic at find_oplock_types().

[Hemanth Thummala]

Richard,

This issue is not related to streams. I have verified that file in use not
having any (alternate) streams on it. And I have tried the rename tests as
well. Tried opening the file from one client and renamed at different place
and as expected this has failed with sharing violation error.

Thanks,
Hemanth.


On Tue, Aug 5, 2014 at 12:38 PM, Richard Sharpe <realrichardsharpe at gmail.com
> wrote:

> On Tue, Aug 5, 2014 at 12:17 PM, Volker Lendecke
> <Volker.Lendecke at sernet.de> wrote:
> > On Tue, Aug 05, 2014 at 11:22:19AM -0700, Hemanth Thummala wrote:
> >> 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.
> >
> > The problem is -- access_mask==0 should have broken the
> > oplock. I don't really see how this could not happen.
>
> As I recall, one of the changes was to use a different file_id than
> the normal one Samba uses, based on a hash of the path (more details
> elided). Is it possible that in this case the code has aliased two
> files together, because my memory of dealing with this bug says that
> it was always related to files being aliased. In the ADS case, streams
> were being aliased to their parent file and causing the problem.
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)
>