| 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
| ||
|
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