From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LtAfu-0000zP-6g for mharc-grub-devel@gnu.org; Sun, 12 Apr 2009 21:09:26 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LtAfr-0000zK-Dw for grub-devel@gnu.org; Sun, 12 Apr 2009 21:09:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LtAfl-0000z8-TD for grub-devel@gnu.org; Sun, 12 Apr 2009 21:09:22 -0400 Received: from [199.232.76.173] (port=56806 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LtAfl-0000z5-N7 for grub-devel@gnu.org; Sun, 12 Apr 2009 21:09:17 -0400 Received: from fg-out-1718.google.com ([72.14.220.153]:22949) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LtAfl-0002Yd-3g for grub-devel@gnu.org; Sun, 12 Apr 2009 21:09:17 -0400 Received: by fg-out-1718.google.com with SMTP id 19so557265fgg.7 for ; Sun, 12 Apr 2009 18:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=O0QVKS4qKt0entb8iL7pHbwNfNxLQ95/30SBrmdBmCU=; b=o160giSE+xc9ioqm2P7vJg8/a+7t5yw9GGrfoaBIuew52F49i8b73F8Fs+37dv8hM1 bf5PlSzRvzeNb454x9CnmkShF4NG+7LR7QLQu5otqhfDk1jgbSpeyVSLKe7LEe+9ffo1 NkWWqBpGPkttmWkgqNNu7NmpcZpfCIFGrdOxs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=KmlIMotz22Au8IM3+QZ6wWn7rZBKer7aY27gFK9m85cX9rm3EyWzhRL8yzk0fFZ07m 3bCIp7YuSK2Q59lPKBvE8mo8FGKka472ONu3Gb4qBY1iDSJEU0jcpjXMZmuDQcXrrMcK wOF7/BBEYsB9xGXBou1T/QHA5tEaOQZYxDCDM= Received: by 10.86.89.20 with SMTP id m20mr4279496fgb.71.1239584955913; Sun, 12 Apr 2009 18:09:15 -0700 (PDT) Received: from ?192.168.1.25? (116-145.62-81.cust.bluewin.ch [81.62.145.116]) by mx.google.com with ESMTPS id d4sm5837954fga.3.2009.04.12.18.09.15 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Apr 2009 18:09:15 -0700 (PDT) Message-ID: <49E290C0.9030700@gmail.com> Date: Mon, 13 Apr 2009 03:09:20 +0200 From: phcoder User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: David Miller References: <1239517755.3887.24.camel@mj> <20090412.010121.183222401.davem@davemloft.net> <49E1C5FA.7080808@gmail.com> <20090412.180208.121488309.davem@davemloft.net> In-Reply-To: <20090412.180208.121488309.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: grub-devel@gnu.org Subject: Re: [PATCH]: grub: Fix ofdisk disk cache corruption. X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 01:09:24 -0000 David Miller wrote: > From: phcoder > Date: Sun, 12 Apr 2009 12:44:10 +0200 > >> David Miller wrote: >>> From: Pavel Roskin >>> Date: Sun, 12 Apr 2009 02:29:15 -0400 >>> >>>> On Sat, 2009-04-11 at 01:08 -0700, David Miller wrote: >>> I think fixing disk cache corruption is more important than >>> arguing over the distribution properties of the hash function >>> I have choosen. >>> >> Yes, but weak hash has exactly the same problem, just on other systems > > Nobody has even shown that the hash is actually weak or > not effective in any particular case, theoretical or otherwise. > > That's why it frustrates me that we're discussing this at all. > > "That hash might not be good, only 3 bits of entropy" meanwhile > we have a disk cache corrupt bug still unfixed. > > Can't we bicker about these kinds of issues after the bug is > fixed? And also, after some proof is given that the hash > matters at all. > > Priorities are definitely wrong here. > >>>> If you can save the device names, then there is no point in using >>>> hashes. You can use (long)devpath. >>> Sure we need the hash, to find path entries we've saved beforehand. >> You can maintain a table of devpathes in cache and use the index in >> this table as id. This way is the safest > > Ummm, that's essentially what my code does, except that the "index" > is the address of the cached path entry itself. Sorry I totally misread your code. Now it's fine -- Regards Vladimir 'phcoder' Serbinenko