From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40847 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OEywh-0003xo-LN for qemu-devel@nongnu.org; Thu, 20 May 2010 02:09:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OEywg-00088p-1F for qemu-devel@nongnu.org; Thu, 20 May 2010 02:09:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9999) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OEywf-00088l-Q0 for qemu-devel@nongnu.org; Thu, 20 May 2010 02:09:25 -0400 Message-ID: <4BF4D208.2090507@redhat.com> Date: Thu, 20 May 2010 09:09:12 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] block: fix sector comparism in multiwrite_req_compare References: <20100519185309.GA27591@lst.de> <20100519193802.GA29104@lst.de> <4BF43F30.4050109@msgid.tls.msk.ru> <201005192309.08252@kevin-wolf.de> In-Reply-To: <201005192309.08252@kevin-wolf.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Kevin Wolf , Michael Tokarev , qemu-devel@nongnu.org, Christoph Hellwig On 05/20/2010 12:09 AM, Kevin Wolf wrote: > >> Actually it's not that obvious. If the actual problem >> here (besides the mis-comparison) is due to missing >> barriers or flushes. Avi asked a good question in that >> thread. >> > It's obvious that it's a hack. It doesn't fix anything, it just disables a > feature that didn't work. Good for debugging, but not something that you > would like to commit. > > It's reasonable to include something like this when we know that something is > broken but we haven't found it yet - but I believe Christoph's patch is the > real fix. If anyone can still find a case that is "fixed" by Avi's patch, I > could be convinced to apply it anyway, but I'd prefer if I didn't have to. > > Note that we actually don't have overlapping requests. It just looks like it > because the qsort call doesn't work correctly with the broken comparison > function, so lower sector numbers can come after higher ones. > I agree my patch didn't fix the problem, only made it disappear, but won't the current code break with overlapping requests? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.