smbd panic at find_oplock_types().

Fri Sep 5 17:35:14 MDT 2014

Created bug for the same.
https://bugzilla.samba.org/show_bug.cgi?id=10797

Thanks,
Hemanth.

On Fri, Sep 5, 2014 at 4:21 PM, Hemanth Thummala <hemanth.thummala at gmail.com
> wrote:

> Hi,
>
> Finally I am able to recreate this smb panic with the help of smbtorture
> test. This issue actually related to alternate data streams. In one of our
> customer core dumps, we could see the file is having alternate data stream.
>
> Here are the steps to recreate the panic:
>
> 1) create some file say oplock.txt.
> 2) create a stream on the file. ex: oplock.txt:stream1
> 3) Open file oplock.txt with BATCH_OPLOCK. do not close the handle
> 4) Open the stream file(oplock.txt:stream1) with or without oplock. Do not
> close the handle here as well.
> 5) Open the base file (oplock.txt) again. You will see smb panic.
>
> Just to remind we are using samba 3.6.12+ stack.
>
> I have reproduced this issue on a freenas server as well which is running
> samba 3.6.12 stack. But did not see much changes in Master code specific to
> this area. We should be hitting the same issue.
>
> Log snippet during panic on freenas:
>
>   parse_share_modes: owrt: Fri Sep  5 14:53:12 2014 PDT, cwrt: Wed Dec 31
> 16:00:00 1969 PST, ntok: 0, num_share_modes: 2
> [2014/09/05 15:01:38.881370, 10] locking/locking.c:725(parse_share_modes)
>   parse_share_modes: share_mode_entry[0]:  pid = 5178, share_access = 0x7,
> private_options = 0x0, access_mask = 0x120089, mid = 0x4, type= 0x2, gen_id
> = 1836070363, uid = 0, flags = 0, file
> _id 1e7aff2c:3616f:0, name_hash = 0x2ab3c7
> [2014/09/05 15:01:38.881384, 10] locking/locking.c:725(parse_share_modes)
>   parse_share_modes: share_mode_entry[1]:  pid = 5178, share_access = 0x7,
> private_options = 0x0, access_mask = 0x0, mid = 0x0, type= 0x0, gen_id =
> 1836070364, uid = 0, flags = 0, file_id 1
> e7aff2c:3616f:0, name_hash = 0x2ab3c7
> [2014/09/05 15:01:38.881394,  0] lib/util.c:1117(smb_panic)
>   PANIC (pid 5178): Bad no oplock entry.
>
>
> I think this is what its happening..
>
> When we successfully open base file step#3, we register a shared mode lock
> with BATCH_OPLOCK on base file. When we try to open the stream file in
> step#4, we are doing an internal open on base file with access mask as
> zero, oplock as zero(NO_OPLOCK) and req as NULL in create_file_unixpath().
>
> In create_file_unixpath()
> ....
> /* Open the base file. */
> status = create_file_unixpath(conn, *NULL*, smb_fname_base,* 0*,
>       FILE_SHARE_READ
>       | FILE_SHARE_WRITE
>       | FILE_SHARE_DELETE,
>       base_create_disposition,
>       0, 0, 0, 0, *0*, NULL, NULL,
>       &base_fsp, NULL);
> TALLOC_FREE(smb_fname_base);
> ...
>
> But we avoid breaking existing batch oplock as we treat this as internal
> open.  In open_file_ntcreate()..
> /* First pass - send break only on batch oplocks. */
> if ((req != NULL) && ===> we skip if req is NULL.
> delay_for_batch_oplocks(fsp,
> req->mid,
> oplock_request,
> batch_entry)) {
> schedule_defer_open(lck, request_time, req);
> TALLOC_FREE(lck);
> return NT_STATUS_SHARING_VIOLATION;
> }
>
> But this entry is also getting added to share mode lock list for the base
> file. Now we have a BATCH_OPLOCK and NO_OPLOCK on base file oplock.txt.
> Next open request on base file is causing to traverse the list and leading
> to panic situation.
>
>
> I have observed that we are actually setting the flag "INTERNAL_OPEN_ONLY"
> in create_file_unixpath when we see the req as NULL.
> ...
> if (req == NULL) {
> oplock_request |= INTERNAL_OPEN_ONLY;
> }
> ...
>
> But in open_file_ntcreate(), we are unconditionally clearing this
> INTERNAL_OPEN_ONLY flag.
>
> ...
> /* Ensure no SAMBA_PRIVATE bits can be set. */
> fsp->oplock_type = (oplock_request & ~SAMBA_PRIVATE_OPLOCK_MASK);
> ....
>
> Due to this, we never treated this shared lock entry as internal.
>
> In find_oplock_types() we have the checks..
>
> ...
> if ((oplock_request & INTERNAL_OPEN_ONLY) ||
> is_stat_open(fsp->access_mask)) {
> return;
> }
> ....
> if (lck->share_modes[i].op_type == NO_OPLOCK &&
> is_stat_open(lck->share_modes[i].access_mask)) {
> /* We ignore stat opens in the table - they
>    always have NO_OPLOCK and never get or
>    cause breaks. JRA. */
> continue;
> }
> ...
>
> This particular shared lock is skipping all these checks. It was neither
> having INTERNAL_OPEN_FLAG nor a stat open(since access mask is zero).
>
> I want to know..
> a) If its intentional to clear the SAMBA_PRIVATE_OPLOCK_MASK before
> adding the lock to share mode list.
> b) Why are we not using access mask as (SYNCHRONIZE_ACCESS|FILE_READ_ATTRIBUTES|
> FILE_WRITE_ATTRIBUTES) which will mark the open as stat_open and will allow
> to skip this share lock check. Thereby avoids panic.
>
> Will file a bug for the same and put more details.
>
> Thanks,
> Hemanth.
>
>
>
> On Tue, Aug 5, 2014 at 3:35 PM, Richard Sharpe <
> realrichardsharpe at gmail.com> wrote:
>
>> 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
>> (何以解憂？唯有杜康。--曹操)
>>
>
>