smbd panic at find_oplock_types().

[Richard Sharpe]

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