From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754855Ab0JOK4m (ORCPT ); Fri, 15 Oct 2010 06:56:42 -0400 Received: from 0122700014.0.fullrate.dk ([95.166.99.235]:48475 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754384Ab0JOK4l (ORCPT ); Fri, 15 Oct 2010 06:56:41 -0400 Message-ID: <4CB8336B.9030400@kernel.dk> Date: Fri, 15 Oct 2010 12:56:43 +0200 From: Jens Axboe MIME-Version: 1.0 To: Tejun Heo CC: lkml , Andrew Morton , Richard Weinberger , "jdike@addtoit.com" , "user-mode-linux-devel@lists.sourceforge.net" , "user-mode-linux-user@lists.sourceforge.net" , "janjaap@bos.nl" , Geert Uytterhoeven , "Martin K. Petersen" , Alexey Dobriyan , "syzop@vulnscan.org" , Chris Frey , stable Subject: Re: [PATCH v2.6.36-rc7] ubd: fix incorrect sector handling during request restart References: <4CB81C91.7070406@kernel.org> In-Reply-To: <4CB81C91.7070406@kernel.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2010-10-15 11:19, Tejun Heo wrote: > Commit f81f2f7c (ubd: drop unnecessary rq->sector manipulation) > dropped request->sector manipulation in preparation for global request > handling cleanup; unfortunately, it incorrectly assumed that the > updated sector wasn't being used. > > ubd tries to issue as many requests as possible to io_thread. When > issuing fails due to memory pressure or other reasons, the device is > put on the restart list and issuing stops. On IO completion, devices > on the restart list are scanned and IO issuing is restarted. > > ubd issues IOs sg-by-sg and issuing can be stopped in the middle of a > request, so each device on the restart queue needs to remember where > to restart in its current request. ubd needs to keep track of the > issue position itself because, > > * blk_rq_pos(req) is now updated by the block layer to keep track of > _completion_ position. > > * Multiple io_req's for the current request may be in flight, so it's > difficult to tell where blk_rq_pos(req) currently is. > > Add ubd->rq_pos to keep track of the issue position and use it to > correctly restart io_req issue. Thanks Tejun, good to see this one resolved. -- Jens Axboe