smbd panic at find_oplock_types().

[Richard Sharpe]

On Tue, Aug 5, 2014 at 3:31 PM, Hemanth Thummala
<hemanth.thummala at gmail.com> wrote:
> 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.

I am not saying that it is related to streams. I am simply mentioning
streams because most of the cases I saw there were related to the
aliasing of a stream to its parent file. Thus, the aliasing of files
is a problem.

Combine that with the fact that the file_id in your version of Samba,
when I last worked on it, was no longer an inode # (and FSID) but a
hash of the path, and there are potential issues with aliasing. It
would most likely occur in a case where the client renamed a file but
held it open.

> 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
>> (何以解憂？唯有杜康。--曹操)
>
>



-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)