Bug 10673 - Increasing response times for byte range unlock requests.
Summary: Increasing response times for byte range unlock requests.
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: SMB2 (show other bugs)
Version: 3.6.12
Hardware: All All
: P5 critical
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-25 06:12 UTC by Hemanth
Modified: 2014-07-27 10:09 UTC (History)
3 users (show)

See Also:

Attachments
.exe files used to test byte range locks. (54.51 KB, application/x-zip-compressed)
2014-06-25 06:12 UTC, Hemanth 		no flags Details
Patch for byte range unlock issue. (627 bytes, text/plain)
2014-06-26 10:24 UTC, Hemanth 		no flags Details
git-am fix for master. (5.32 KB, patch)
2014-06-26 19:13 UTC, Jeremy Allison 		no flags Details
git-am fix for 4.1.next and 4.0.next. (5.89 KB, patch)
2014-07-01 22:43 UTC, Jeremy Allison 		ira: review+
vl: review+
Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Hemanth 2014-06-25 06:12:57 UTC 
Created attachment 10051 [details]
.exe files used to test byte range locks.

Observing increasing response times for unlock requests when running a byte range lock test. From the debug logs and code-walk through, I found that pending wait entries are not being cleanup when they get reprocessed successfully. Due to this all pending entries piling up and causing the delay in completing the byte range unlock request.
Comment 1 Hemanth 2014-06-26 10:24:45 UTC 
Created attachment 10055 [details]
Patch for byte range unlock issue.

Here I am attaching the patch which fixes this issue. brl_lock_cancel() is called on successful reprocess of blocking lock requests. 

Tested these changes with the help of attached test scripts in the bug. No degradation observed on consecutive runs.

Please let me know if this looks good.
Comment 2 Jeremy Allison 2014-06-26 18:20:04 UTC 
Sorry, still working on the patch for master. I'm going to simplify this code a bit more.

Cheers,

Jeremy.
Comment 3 Jeremy Allison 2014-06-26 19:13:15 UTC 
Created attachment 10056 [details]
git-am fix for master.

Here's the fix I'd like to use. A little more extensive than your change Hemanth, but I think it simplifies all the logic around here. Once it passes make test in master I'll submit to samba-technical.

If you can test it with your test case as well I'd appreciate it !

Thanks,

Jeremy.
Comment 4 Hemanth 2014-06-27 07:22:30 UTC 
(In reply to comment #3)
> Created attachment 10056 [details]
> git-am fix for master.
> 
> Here's the fix I'd like to use. A little more extensive than your change
> Hemanth, but I think it simplifies all the logic around here. Once it passes
> make test in master I'll submit to samba-technical.
> 
> If you can test it with your test case as well I'd appreciate it !
> 
> Thanks,
> 
> Jeremy.

Thanks Jeremy. 
I have tested the changes from end. Results are good. Patch also looks clean.

Thanks,
Hemanth.
Comment 5 Jeremy Allison 2014-07-01 22:43:34 UTC 
Created attachment 10063 [details]
git-am fix for 4.1.next and 4.0.next.

Patchset that went into master, cherry-picked for 4.1.next and 4.0.next.

Ira, if you can +1 it we'll get it into the next releases.

Thanks,

Jeremy.
Comment 6 Jeremy Allison 2014-07-01 23:11:36 UTC 
Re-assigning to Karolin for inclusion in 4.0.next, 4.1.next.
Comment 7 Karolin Seeger 2014-07-17 18:22:01 UTC 
(In reply to comment #6)
> Re-assigning to Karolin for inclusion in 4.0.next, 4.1.next.

Pushed to autobuild-v-4-[0|1]-test.
Comment 8 Karolin Seeger 2014-07-27 10:09:08 UTC 
(In reply to comment #7)
> (In reply to comment #6)
> > Re-assigning to Karolin for inclusion in 4.0.next, 4.1.next.
> 
> Pushed to autobuild-v-4-[0|1]-test.

Pushed to both branches.
Closing out bug report.

Thanks!