smbd panic at find_oplock_types().

Richard Sharpe realrichardsharpe at gmail.com
Tue Aug 5 14:07:01 MDT 2014


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.

And, as I mentioned while I was there, how does rename interact with
this. It seems likely that there can be a race where the wrong things
can happen with locking when one client renames a file ...

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


More information about the samba-technical mailing list