Hi,
In Linux Device Drivers, chapter 16 about Block Devices, page 12-13, a
simple block device request() method is presented:
static void sbull_request(request_queue_t *q)
{
struct request *req;
while ((req = elv_next_request(q)) != NULL) {
struct sbull_dev *dev = req->rq_disk->private_data;
if (! blk_fs_request(req)) {
printk (KERN_NOTICE "Skip non-fs request\n");
end_request(req, 0);
continue;
}
sbull_transfer(dev, req->sector, req->current_nr_sectors,
req->buffer, rq_data_dir(req));
end_request(req, 1);
}
}
This method uses the rq->buffer field of the struct request to get the
location of the information to be written (or the location at which
information read from the device should be stored).
>From by understanding, this field is updated at each
end_request() by blk_recalc_rq_sectors(), so that at each iteration of
the loop, rq->buffer will be different. Is that correct ?
blk_recalc_rq_sectors() uses bio_data() to compute the address at which
the data should be read/written. But this bio_data() uses
page_address(), which only works if the page is in ZONE_NORMAL, not in
ZONE_HIGHMEM. This fact is highlighted in <linux/bio.h> :
/*
* various member access, note that bio_data should of course not be used
* on highmem page vectors
*/
So, who is doing the bounce buffering of the bio page when it's stored
in ZONE_HIGHMEM ? Is it safe for a block driver to blindly use
rq->buffer without knowing if the bio's page is in HIGHMEM or not ?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
