[PATCH] Fix bug 9722 - Samba does not properly handle Oplock breaks in compound requests
Jeremy Allison
jra at samba.org
Mon May 6 11:01:32 MDT 2013
On Sat, May 04, 2013 at 08:30:43PM -0700, Richard Sharpe wrote:
> On Sat, May 4, 2013 at 8:14 PM, Richard Sharpe
> <realrichardsharpe at gmail.com> wrote:
> > On Fri, May 3, 2013 at 11:19 AM, Jeremy Allison <jra at samba.org> wrote:
> >> Here is a bugfix for master for Bug 9722, discovered by Richard.
> >>
> >> It includes a torture test (written by Richard) that
> >> reproduces the Windows client test case that discovered
> >> the bug.
> >>
> >> Passes all testing here (I've also tested with SMB3
> >> encryption turned on :-).
> >>
> >> Please review and push if you approve.
> >
> > Is there a problem here?
> >
> > diff --git a/source3/smbd/smb2_server.c b/source3/smbd/smb2_server.c
> > index 57e9c7b..9a55d6a 100644
> > --- a/source3/smbd/smb2_server.c
> > +++ b/source3/smbd/smb2_server.c
> > @@ -1599,6 +1599,14 @@ static NTSTATUS smbd_smb2_request_process_cancel(struct s
> > mbd_smb2_request *req)
> > uint64_t message_id;
> > uint64_t async_id;
> >
> > + if (cur->compound_related) {
> > + /*
> > + * Never cancel anything in a compound request.
> > + * Way too hard to deal with the result.
> > + */
> > + continue;
> > + }
> > +
> > outhdr = SMBD_SMB2_OUT_HDR_PTR(cur);
> >
> > message_id = BVAL(outhdr, SMB2_HDR_MESSAGE_ID);
> > --
> > 1.8.1.2
> >
> > because just before the for loop that this goes in, we do this:
> >
> > /*
> > * we don't need the request anymore
> > * cancel requests never have a response
> > */
> > DLIST_REMOVE(req->sconn->smb2.requests, req);
> > TALLOC_FREE(req);
> >
> > which seems to suggest that the request is now gone from our view.
>
> OK, I only have this one question about this patch series. After that
> I am happy to push.
Hopefully my previous email explains this and so you will
push today :-).
Cheers,
Jeremy.
More information about the samba-technical
mailing list