Bug 7744 - "dfree cache time" doesn't work.
Summary: "dfree cache time" doesn't work.
Alias: None
Product: Samba 3.5
Classification: Unclassified
Component: File services (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
Depends on:
Reported: 2010-10-20 15:58 UTC by Jeremy Allison
Modified: 2010-11-11 05:12 UTC (History)
0 users

See Also:

git-am fix for 3.5.x. (2.26 KB, patch)
2010-10-20 16:01 UTC, Jeremy Allison
vl: review+

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Allison 2010-10-20 15:58:23 UTC
There is a bug in processing the dfree cache time, which is associated with the smbd idle timer. The idle timer call conn_idle_all(), which updates the conn->lastused timestamp. The dfree cache time code in smbd/dfree.c depends on conn->lastused being up to date to refresh the cached dfree value.

Unfortunately the conn_idle_all() returns early if any of the connection structs is not idle, never updating any further conn->lastused timestamps. If (as is common due to an IPC$ connection) there are more than one used connection struct, then the conn->lastused timestamps after the IPC$ connection in the connection list will never be updated.

This has been fixed in v3-6-test and master, patch to follow.

Comment 1 Jeremy Allison 2010-10-20 16:01:35 UTC
Created attachment 6028 [details]
git-am fix for 3.5.x.

This patch has been tested by the OEM that reported the problem and has confirmed it fixed the bug.

Once reviewed please reassign to Karolin for 3.5.next.


Comment 2 Volker Lendecke 2010-10-21 03:16:46 UTC
Comment on attachment 6028 [details]
git-am fix for 3.5.x.

Jeremy, can you please explain how this is fixed in master? In master I still see an early "return false;" in conn_idle_all.
Comment 3 Jeremy Allison 2010-10-21 11:40:05 UTC
In master I moved the update of the timestamps to another function : 

conn_lastused_update(sconn, t);

which I call before doing any timestamp comparisons. It was very confusing to be both updating the timstamps at the same time we're deciding if they've changed (and I believe that mix-up to be the source of the bug). Once conn_lastused_update() has updated all the timestamps conn_idle_all() is free to return early if it finds a changed timestamp - we know the TCP connection as a whole isn't idle.


Comment 4 Karolin Seeger 2010-11-11 05:12:51 UTC
Pushed to v3-5-test.
Closing out bug report.