On Tue, Oct 30, 2012 at 05:37:31PM -0700, Sage Weil wrote: > On Tue, 30 Oct 2012, Greg KH wrote: > > On Tue, Oct 30, 2012 at 04:47:52PM -0700, Sage Weil wrote: > > > If ceph_fault() is unable to queue work after a delay, it sets the > > > BACKOFF connection flag so con_work() will attempt to do so. > > > > > > In con_work(), when BACKOFF is set, if queue_delayed_work() doesn't > > > result in newly-queued work, it simply ignores this condition and > > > proceeds as if no backoff delay were desired. There are two > > > problems with this--one of which is a bug. > > > > > > The first problem is simply that the intended behavior is to back > > > off, and if we aren't able queue the work item to run after a delay > > > we're not doing that. > > > > > > The only reason queue_delayed_work() won't queue work is if the > > > provided work item is already queued. In the messenger, this > > > means that con_work() is already scheduled to be run again. So > > > if we simply set the BACKOFF flag again when this occurs, we know > > > the next con_work() call will again attempt to hold off activity > > > on the connection until after the delay. > > > > > > The second problem--the bug--is a leak of a reference count. If > > > queue_delayed_work() returns 0 in con_work(), con->ops->put() drops > > > the connection reference held on entry to con_work(). However, > > > processing is (was) allowed to continue, and at the end of the > > > function a second con->ops->put() is called. > > > > > > This patch fixes both problems. > > > > > > [Upstream commit 588377d6199034c36d335e7df5818b731fea072c) > > > > What stable tree(s) do you want this applied to? > > Sorry- this series is for 3.6.x. Thanks!
Why? It seems that some of these should also go to older kernels, like 3.4 and 3.0, right? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
