Accesing block device from kernel module

Question

I am interested in developing kernel module that binds two block devices into a new block device in such manner that first block device contains data at mount time, and the other is considered empty. Every write is being made to second partition, so on next mount the base filesystem remains unchanged. I know of solutions like UnionFS, but those are filesystem-based, while i want to develop it a layer lower, block-based.

Can anyone tell me how could i open ad read/write block device from kernel module? Possibly without using userspace program for reading/writing merged block devices. I found similar topic here, but the answer was rather unsatysfying because filp_* functions are rather for reading small config files, not for (large) block device I/O.

Since interface for creating block devices is standarized i was thinking of direct (or almost direct) acces to functions implementing source devices, as i will be requested to export similar functions anyway. If i could do that i would simply create some proxy-functions calling appropriate functions on source devices. Can i somehow obtain pointer to a gendisk structure that belongs to different driver?

This serves only my own purposes (satisfying quriosity being main of them) so i am not worried about messing my kernel up seriously.

Or does somebody know if module like that already exists?

Answer 1

The source code in the device mapper driver will suit your needs. Look at the code in the Linux source in Linux/drivers/md/dm-*.

You don't need to access the other device's gendisk structure, but rather its request queue. You can prepare I/O requests and push it down the other device's queue, and it will do the rest itself.

I have implemented a simple block device that opens another block device. Take a look in my post describing it: stackbd: Stacking a block device over another block device

Here are some examples of functions that you need for accessing another device's gendisk. The way to open another block device using its path ("/dev/"):

struct block_device *bdev_raw = lookup_bdev(dev_path);
printk("Opened %s\n", dev_path);
if (IS_ERR(bdev_raw))
{
    printk("stackbd: error opening raw device <%lu>\n", PTR_ERR(bdev_raw));
    return NULL;
}
if (!bdget(bdev_raw->bd_dev))
{
    printk("stackbd: error bdget()\n");
    return NULL;
}
if (blkdev_get(bdev_raw, STACKBD_BDEV_MODE, &stackbd))
{
    printk("stackbd: error blkdev_get()\n");
    bdput(bdev_raw);
    return NULL;
}

The simplest example of passing an I/O request from one device to another is by remapping it without modifying it. Notice in the following code that the bi_bdev entry is modified with a different device. One can also modify the block address (*bi_sector) and the data itself.

static void stackbd_io_fn(struct bio *bio)
{
    bio->bi_bdev = stackbd.bdev_raw;

    trace_block_bio_remap(bdev_get_queue(stackbd.bdev_raw), bio,
            bio->bi_bdev->bd_dev, bio->bi_sector);

    /* No need to call bio_endio() */
    generic_make_request(bio);
}

Answer 2

Consider examining the code for the dm / md block devices in drivers/md - these existing drivers create a block device that stores data on other block devices.

In fact, you could probably implement your idea as another "RAID personality" in md, and thereby make use of the existing userspace tools for setting up the devices.

Answer 3

You know, if you're a GPL'd kernel module you can just call open(), read(), write(), etc. from kernel mode right?

Of course this way has certain caveats including requiring forking from kernel mode to create a space for your handle to live.