smbd panic at find_oplock_types().

[Hemanth Thummala]

Hi Volker,

Thanks for quick patch. From these changes, I understood that we are trying
to skip any shared mode entry found in lock database with mid as zero.
Shouldn't we be restricting to add the database if we have mid as zero. May
be I am trying to understand the reason for keeping the shared mode entries
made by internal opens.

Probably we can restrict set_share_mode() only if req is non-NULL.

something like this...

@@ -2433,9 +2433,11 @@ static NTSTATUS open_file_ntcreate(conne
                new_file_created = True;
        }

-       set_share_mode(lck, fsp, get_current_uid(conn),
-                       req ? req->mid : 0,
-                      fsp->oplock_type);
+       if (req != NULL) {
+               set_share_mode(lck, fsp, get_current_uid(conn),
+                               req->mid,
+                               fsp->oplock_type);
+       }

This way, we will never add internal shared mode locks to data base.

Want to check with you before I really test these changes. Please correct
me I am wrong.

Thanks,
Hemanth.

On Tue, Sep 9, 2014 at 4:12 AM, Volker Lendecke <Volker.Lendecke at sernet.de>
wrote:

> On Sat, Sep 06, 2014 at 09:55:40AM -0700, Jeremy Allison wrote:
> > On Sat, Sep 06, 2014 at 09:50:25AM -0700, Jeremy Allison wrote:
> > >
> > > INTERNAL_OPEN_ONLY is a synonym for req==NULL,
> > > and we probably can now just remove it as a
> > > flag ever passed into SMB_VFS_CREATE_FILE(),
> > > at least in master. It represents an open that
> > > is being done on behalf of the smbd to achieve
> > > another task, and not at the direct request of
> > > the client (which is why req == NULL).
> >
> > Yeah, looking inside master in open_file_ntcreate()
> > we have:
> >
> >         if (req == NULL) {
> >                 /* Ensure req == NULL means INTERNAL_OPEN_ONLY */
> >                 SMB_ASSERT(((oplock_request & INTERNAL_OPEN_ONLY) != 0));
> >         } else {
> >                 /* And req != NULL means no INTERNAL_OPEN_ONLY */
> >                 SMB_ASSERT(((oplock_request & INTERNAL_OPEN_ONLY) == 0));
> >         }
> >
> > so once we've fixed this we can add a patch
> > that removes all uses of INTERNAL_OPEN_ONLY
> > from all other files except open.c, and moves
> > this block of header:
>
> Remember that INTERNAL_OPEN_ONLY has the effect that this request will
> never be deferred. For me that's the main use of this flag: Not all
> callers are prepared to handle open_was_deferred. We need an indication
> to open_file_ntcreate to never defer a call. Or even better, we need to
> replace the existing deferral mechanism with a tevent_req based design,
> but that's certainly a future project.
>
> What about the attached patch? This fixes batch26. I haven't
> run an autobuild yet, starting that in a minute.
>
> Volker
>
> --
> SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
> phone: +49-551-370000-0, fax: +49-551-370000-9
> AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
> http://www.sernet.de, mailto:kontakt at sernet.de
>