From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.2ka.mipt.ru ([194.85.82.65] helo=2ka.mipt.ru) by canuck.infradead.org with esmtp (Exim 4.63 #1 (Red Hat Linux)) id 1HppGF-0006ne-8M for linux-mtd@lists.infradead.org; Sun, 20 May 2007 13:32:05 -0400 Date: Sun, 20 May 2007 21:30:52 +0400 From: Evgeniy Polyakov To: =?utf-8?B?SsO2cm4=?= Engel Subject: Re: Review status (Re: [PATCH] LogFS take three) Message-ID: <20070520173049.GA20907@2ka.mipt.ru> References: <20070515151919.GA32510@lazybastard.org> <20070515152149.GB32059@lazybastard.org> <20070517160308.GA26643@2ka.mipt.ru> <20070517171017.GB15676@lazybastard.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070517171017.GB15676@lazybastard.org> Cc: akpm@osdl.org, Albert Cahalan , Greg KH , linux-kernel@vger.kernel.org, Ingo Oeser , Pekka Enberg , linux-mtd@lists.infradead.org, Jan Engelhardt , linux-fsdevel@vger.kernel.org, Thomas Gleixner List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, May 17, 2007 at 07:10:19PM +0200, Jörn Engel (joern@lazybastard.org) wrote: > On Thu, 17 May 2007 20:03:11 +0400, Evgeniy Polyakov wrote: > > > > Is logfs 32bit fs or 674bit, since although you use 64bit values for > > offsets, area management and strange converstions like described below > > from offset into segment number are performed in 32bit? > > Is it enough for SSD for example to be 32bit only? Or if it is 64bit, > > could you please explain logic behind area management? > > Ignoring bugs and signed return values for error handling, it is either > 64bit or 32+32bit. > > Inode numbers and file positions are 64bit. Offsets are 64bit as well. > In a couple of places, offsets are also 32+32bit. Basically the high > bits contain the segment number, the lower bits the offset within a > segment. In that case segment size must be more than 32 bits, or below transformation will not be correct? segsize is long, but should be u64 I think. static void fixup_from_wbuf(struct super_block *sb, struct logfs_area *area, void *read, u64 ofs, size_t readlen) u32 read_start = ofs & (super->s_segsize - 1); u32 read_end = read_start + readlen; And this can overflow, since readlen is size_t. It is wbuf fixup, but I saw that somewhere else. Although, according to your description, it should be 32bit, sum can be more than 32 bit. > If anyone can find similar bugs, the bounty is a beer or non-alcoholic > beverage of choice. :) Stop kiling your kidneys, your health and promote such antisocial style of life, start drinking vodka instead. > Jörn -- Evgeniy Polyakov From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759129AbXETRdI (ORCPT ); Sun, 20 May 2007 13:33:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756638AbXETRcz (ORCPT ); Sun, 20 May 2007 13:32:55 -0400 Received: from relay.2ka.mipt.ru ([194.85.82.65]:43405 "EHLO 2ka.mipt.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756362AbXETRcx (ORCPT ); Sun, 20 May 2007 13:32:53 -0400 Date: Sun, 20 May 2007 21:30:52 +0400 From: Evgeniy Polyakov To: =?utf-8?B?SsO2cm4=?= Engel Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, akpm@osdl.org, Albert Cahalan , Thomas Gleixner , Jan Engelhardt , Pekka Enberg , Greg KH , Ingo Oeser Subject: Re: Review status (Re: [PATCH] LogFS take three) Message-ID: <20070520173049.GA20907@2ka.mipt.ru> References: <20070515151919.GA32510@lazybastard.org> <20070515152149.GB32059@lazybastard.org> <20070517160308.GA26643@2ka.mipt.ru> <20070517171017.GB15676@lazybastard.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070517171017.GB15676@lazybastard.org> User-Agent: Mutt/1.5.9i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (2ka.mipt.ru [0.0.0.0]); Sun, 20 May 2007 21:31:04 +0400 (MSD) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 17, 2007 at 07:10:19PM +0200, Jörn Engel (joern@lazybastard.org) wrote: > On Thu, 17 May 2007 20:03:11 +0400, Evgeniy Polyakov wrote: > > > > Is logfs 32bit fs or 674bit, since although you use 64bit values for > > offsets, area management and strange converstions like described below > > from offset into segment number are performed in 32bit? > > Is it enough for SSD for example to be 32bit only? Or if it is 64bit, > > could you please explain logic behind area management? > > Ignoring bugs and signed return values for error handling, it is either > 64bit or 32+32bit. > > Inode numbers and file positions are 64bit. Offsets are 64bit as well. > In a couple of places, offsets are also 32+32bit. Basically the high > bits contain the segment number, the lower bits the offset within a > segment. In that case segment size must be more than 32 bits, or below transformation will not be correct? segsize is long, but should be u64 I think. static void fixup_from_wbuf(struct super_block *sb, struct logfs_area *area, void *read, u64 ofs, size_t readlen) u32 read_start = ofs & (super->s_segsize - 1); u32 read_end = read_start + readlen; And this can overflow, since readlen is size_t. It is wbuf fixup, but I saw that somewhere else. Although, according to your description, it should be 32bit, sum can be more than 32 bit. > If anyone can find similar bugs, the bounty is a beer or non-alcoholic > beverage of choice. :) Stop kiling your kidneys, your health and promote such antisocial style of life, start drinking vodka instead. > Jörn -- Evgeniy Polyakov From mboxrd@z Thu Jan 1 00:00:00 1970 From: Evgeniy Polyakov Subject: Re: Review status (Re: [PATCH] LogFS take three) Date: Sun, 20 May 2007 21:30:52 +0400 Message-ID: <20070520173049.GA20907@2ka.mipt.ru> References: <20070515151919.GA32510@lazybastard.org> <20070515152149.GB32059@lazybastard.org> <20070517160308.GA26643@2ka.mipt.ru> <20070517171017.GB15676@lazybastard.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: akpm@osdl.org, Albert Cahalan , Greg KH , linux-kernel@vger.kernel.org, Ingo Oeser , Pekka Enberg , linux-mtd@lists.infradead.org, Jan Engelhardt , linux-fsdevel@vger.kernel.org, Thomas Gleixner To: =?utf-8?B?SsO2cm4=?= Engel Return-path: Content-Disposition: inline In-Reply-To: <20070517171017.GB15676@lazybastard.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+gldm-linux-mtd-36=gmane.org+gldm-linux-mtd-36=gmane.org@lists.infradead.org List-Id: linux-fsdevel.vger.kernel.org T24gVGh1LCBNYXkgMTcsIDIwMDcgYXQgMDc6MTA6MTlQTSArMDIwMCwgSsO2cm4gRW5nZWwgKGpv ZXJuQGxhenliYXN0YXJkLm9yZykgd3JvdGU6Cj4gT24gVGh1LCAxNyBNYXkgMjAwNyAyMDowMzox MSArMDQwMCwgRXZnZW5peSBQb2x5YWtvdiB3cm90ZToKPiA+IAo+ID4gSXMgbG9nZnMgMzJiaXQg ZnMgb3IgNjc0Yml0LCBzaW5jZSBhbHRob3VnaCB5b3UgdXNlIDY0Yml0IHZhbHVlcyBmb3IKPiA+ IG9mZnNldHMsIGFyZWEgbWFuYWdlbWVudCBhbmQgc3RyYW5nZSBjb252ZXJzdGlvbnMgbGlrZSBk ZXNjcmliZWQgYmVsb3cgCj4gPiBmcm9tIG9mZnNldCBpbnRvIHNlZ21lbnQgbnVtYmVyIGFyZSBw ZXJmb3JtZWQgaW4gMzJiaXQ/Cj4gPiBJcyBpdCBlbm91Z2ggZm9yIFNTRCBmb3IgZXhhbXBsZSB0 byBiZSAzMmJpdCBvbmx5PyBPciBpZiBpdCBpcyA2NGJpdCwKPiA+IGNvdWxkIHlvdSBwbGVhc2Ug ZXhwbGFpbiBsb2dpYyBiZWhpbmQgYXJlYSBtYW5hZ2VtZW50Pwo+IAo+IElnbm9yaW5nIGJ1Z3Mg YW5kIHNpZ25lZCByZXR1cm4gdmFsdWVzIGZvciBlcnJvciBoYW5kbGluZywgaXQgaXMgZWl0aGVy Cj4gNjRiaXQgb3IgMzIrMzJiaXQuCj4gCj4gSW5vZGUgbnVtYmVycyBhbmQgZmlsZSBwb3NpdGlv bnMgYXJlIDY0Yml0LiAgT2Zmc2V0cyBhcmUgNjRiaXQgYXMgd2VsbC4KPiBJbiBhIGNvdXBsZSBv ZiBwbGFjZXMsIG9mZnNldHMgYXJlIGFsc28gMzIrMzJiaXQuICBCYXNpY2FsbHkgdGhlIGhpZ2gK PiBiaXRzIGNvbnRhaW4gdGhlIHNlZ21lbnQgbnVtYmVyLCB0aGUgbG93ZXIgYml0cyB0aGUgb2Zm c2V0IHdpdGhpbiBhCj4gc2VnbWVudC4KCkluIHRoYXQgY2FzZSBzZWdtZW50IHNpemUgbXVzdCBi ZSBtb3JlIHRoYW4gMzIgYml0cywgb3IgYmVsb3cKdHJhbnNmb3JtYXRpb24gd2lsbCBub3QgYmUg Y29ycmVjdD8gc2Vnc2l6ZSBpcyBsb25nLCBidXQgc2hvdWxkIGJlIHU2NCBJCnRoaW5rLgoKc3Rh dGljIHZvaWQgZml4dXBfZnJvbV93YnVmKHN0cnVjdCBzdXBlcl9ibG9jayAqc2IsIHN0cnVjdCBs b2dmc19hcmVhCgkqYXJlYSwgdm9pZCAqcmVhZCwgdTY0IG9mcywgc2l6ZV90IHJlYWRsZW4pCgp1 MzIgcmVhZF9zdGFydCA9IG9mcyAmIChzdXBlci0+c19zZWdzaXplIC0gMSk7CnUzMiByZWFkX2Vu ZCA9IHJlYWRfc3RhcnQgKyByZWFkbGVuOwoKQW5kIHRoaXMgY2FuIG92ZXJmbG93LCBzaW5jZSBy ZWFkbGVuIGlzIHNpemVfdC4KSXQgaXMgd2J1ZiBmaXh1cCwgYnV0IEkgc2F3IHRoYXQgc29tZXdo ZXJlIGVsc2UuCkFsdGhvdWdoLCBhY2NvcmRpbmcgdG8geW91ciBkZXNjcmlwdGlvbiwgaXQgc2hv dWxkIGJlIDMyYml0LCBzdW0gY2FuIGJlCm1vcmUgdGhhbiAzMiBiaXQuCgo+IElmIGFueW9uZSBj YW4gZmluZCBzaW1pbGFyIGJ1Z3MsIHRoZSBib3VudHkgaXMgYSBiZWVyIG9yIG5vbi1hbGNvaG9s aWMKPiBiZXZlcmFnZSBvZiBjaG9pY2UuIDopCgpTdG9wIGtpbGluZyB5b3VyIGtpZG5leXMsIHlv dXIgaGVhbHRoIGFuZCBwcm9tb3RlIHN1Y2ggYW50aXNvY2lhbCBzdHlsZQpvZiBsaWZlLCBzdGFy dCBkcmlua2luZyB2b2RrYSBpbnN0ZWFkLgoKPiBKw7ZybgoKLS0gCglFdmdlbml5IFBvbHlha292 CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K TGludXggTVREIGRpc2N1c3Npb24gbWFpbGluZyBsaXN0Cmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQu b3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtbXRkLwo=