smbd panic at find_oplock_types().
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:
>>> 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_WRITE
>>> | FILE_SHARE_DELETE,
>>> 0, 0, 0==> oplock, 0, 0, NULL, NULL,
>>> &base_fsp, NULL);
>>> 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 ...
More information about the samba-technical