linux-kernel - Re: [patch] ext2: xip check fix

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 6 Dec 2007 11:18:48 +0100
From:	Nick Piggin <npiggin@...e.de>
To:	carsteno@...ibm.com
Cc:	Christian Borntraeger <borntraeger@...ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andrew Morton <akpm@...ux-foundation.org>, rob@...dley.net,
	Jens Axboe <axboe@...nel.dk>
Subject: Re: [patch] ext2: xip check fix

On Thu, Dec 06, 2007 at 10:59:02AM +0100, Carsten Otte wrote:
> Nick Piggin wrote:
> >After my patch, we can do XIP in a hardsect size < PAGE_SIZE block
> >device -- this seems to be a fine thing to do at least for the
> >ramdisk code. Would this situation be problematic for existing drivers,
> >and if so, in what way?
> I have done some archeology, and our ancient CVS logs show this check 
> was introduced in early 2005 into our 2.6.x. codebase. However, it 
> existed way before, and was copied from our prehistorical ext2 split 
> named xip2 back in the old days of 2.4.x where we did not really have 
> a block device behind because that one was scamped into the file 
> system in a very queer way.

OK, thanks for taking a look at that. It will be helpful for testing
XIP with my new ramdisk driver (did you see the patch?).


> After all, I don't see any risk in removing the check. The only driver 
> we have that does direct_access is drivers/s390/block/dcssblk.c, and 
> that one only supports block_size == PAGE_SIZE. I think the patch 
> should go into mainline.

Actually another one's recently sprung up too (arch/powerpc/sysdev/axonram.c)
but it looks like that one should be fine as it looks to be all simply memory
mapped.

 
> Acked-by: Carsten Otte <cotte@...ibm.com>

Thanks! Andrew, would you queue this up for 2.6.25 please?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/