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
| ||
|
Message-ID: <20071204130326.GA19041@wotan.suse.de> Date: Tue, 4 Dec 2007 14:03:26 +0100 From: Nick Piggin <npiggin@...e.de> To: Duane Griffin <duaneg@...da.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: [patch] rd: support XIP (updated) On Tue, Dec 04, 2007 at 12:06:23PM +0000, Duane Griffin wrote: > On 04/12/2007, Nick Piggin <npiggin@...e.de> wrote: > > + gfp_flags = GFP_NOIO | __GFP_ZERO; > > +#ifndef CONFIG_BLK_DEV_XIP > > + gfp_flags |= __GFP_HIGHMEM; > > +#endif > > page = alloc_page(GFP_NOIO | __GFP_HIGHMEM | __GFP_ZERO); > > I think that should be alloc_page(gfp_flags), no? Yes. Here is a resend. Andrew, please apply this one (has passed some testing with ext2 XIP). -- Support direct_access XIP method with brd. Signed-off-by: Nick Piggin <npiggin@...e.de> --- Index: linux-2.6/drivers/block/Kconfig =================================================================== --- linux-2.6.orig/drivers/block/Kconfig +++ linux-2.6/drivers/block/Kconfig @@ -346,6 +346,16 @@ config BLK_DEV_RAM_SIZE The default value is 4096 kilobytes. Only change this if you know what you are doing. +config BLK_DEV_XIP + bool "Support XIP filesystems on RAM block device" + depends on BLK_DEV_RAM + default n + help + Support XIP filesystems (such as ext2 with XIP support on) on + top of block ram device. This will slightly enlarge the kernel, and + will prevent RAM block device backing store memory from being + allocated from highmem (only a problem for highmem systems). + config CDROM_PKTCDVD tristate "Packet writing on CD/DVD media" depends on !UML Index: linux-2.6/drivers/block/brd.c =================================================================== --- linux-2.6.orig/drivers/block/brd.c +++ linux-2.6/drivers/block/brd.c @@ -89,6 +89,7 @@ static struct page *brd_insert_page(stru { pgoff_t idx; struct page *page; + gfp_t gfp_flags; page = brd_lookup_page(brd, sector); if (page) @@ -97,8 +98,17 @@ static struct page *brd_insert_page(stru /* * Must use NOIO because we don't want to recurse back into the * block or filesystem layers from page reclaim. + * + * Cannot support XIP and highmem, because our ->direct_access + * routine for XIP must return memory that is always addressable. + * If XIP was reworked to use pfns and kmap throughout, this + * restriction might be able to be lifted. */ - page = alloc_page(GFP_NOIO | __GFP_HIGHMEM | __GFP_ZERO); + gfp_flags = GFP_NOIO | __GFP_ZERO; +#ifndef CONFIG_BLK_DEV_XIP + gfp_flags |= __GFP_HIGHMEM; +#endif + page = alloc_page(gfp_flags); if (!page) return NULL; @@ -307,6 +317,28 @@ out: return 0; } +#ifdef CONFIG_BLK_DEV_XIP +static int brd_direct_access (struct block_device *bdev, sector_t sector, + unsigned long *data) +{ + struct brd_device *brd = bdev->bd_disk->private_data; + struct page *page; + + if (!brd) + return -ENODEV; + if (sector & (PAGE_SECTORS-1)) + return -EINVAL; + if (sector + PAGE_SECTORS > get_capacity(bdev->bd_disk)) + return -ERANGE; + page = brd_insert_page(brd, sector); + if (!page) + return -ENOMEM; + *data = (unsigned long)page_address(page); + + return 0; +} +#endif + static int brd_ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg) { @@ -342,8 +374,11 @@ static int brd_ioctl(struct inode *inode } static struct block_device_operations brd_fops = { - .owner = THIS_MODULE, - .ioctl = brd_ioctl, + .owner = THIS_MODULE, + .ioctl = brd_ioctl, +#ifdef CONFIG_BLK_DEV_XIP + .direct_access = brd_direct_access, +#endif }; /* -- 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/
Powered by blists - more mailing lists