Skip to contentSkip to conversation

BUG: nr_phys_segments cannot be less than nr_hw_segments

PATCH In review Nikanth Karthikesan 4 participants 12 messages Oct 2, 2008 – Oct 10, 2008

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 BUG: nr_phys_segments cannot be less than nr_hw_segments

This is a follow-up to my earlier mail http://lkml.org/lkml/2008/9/23/294
([PATCH] BUG: ll_merge_requests_fn() updates req->nr_phys_segments wrongly)

It is possible for the merging code to create lesser no of phys segments than hw segments, but every hw segment needs atleast one new phys segment. This triggers the BUG() on scsi_init_sgtable() as blk_rq_map_sg() returns more no of segments than rq->nr_phys_segments

The following blktrace shows a sequence of bio's to trigger such condition on my machine with max_sectors_kb=512 & max_hw_sectors_kb=32767.

  8,0    0       12     1.943680621  2261  Q   R 6184075 + 55 [bash]
  8,0    0       13     1.943684671  2261  G   R 6184075 + 55 [bash]
  8,0    0       14     1.943690189  2261  P   N [bash]
  8,0    0       15     1.943692075  2261  I   R 6184075 + 55 [bash]
  8,0    0       16     1.943712119  2261  D   R 6184075 + 55 [bash]
  8,0    0       17     1.943718684  2261  Q   R 6184130 + 55 [bash]
  8,0    0       18     1.943721897  2261  G   R 6184130 + 55 [bash]
  8,0    0       19     1.943726576  2261  P   N [bash]
  8,0    0       20     1.943727763  2261  I   R 6184130 + 55 [bash]
  8,0    0       21     1.943731675  2261  Q   R 6184241 + 56 [bash]
  8,0    0       22     1.943735167  2261  G   R 6184241 + 56 [bash]
  8,0    0       23     1.943739497  2261  I   R 6184241 + 56 [bash]
  8,0    0       24     1.943742081  2261  Q   R 6184185 + 56 [bash]
  8,0    0       25     1.943744875  2261  M   R 6184185 + 56 [bash]
  8,0    0       26     1.943753535  2261  Q   R 6184352 + 55 [bash]
  8,0    0       27     1.943756538  2261  G   R 6184352 + 55 [bash]
  8,0    0       28     1.943760868  2261  I   R 6184352 + 55 [bash]
  8,0    0       29     1.943763522  2261  Q   R 6184407 + 55 [bash]
  8,0    0       30     1.943766316  2261  M   R 6184407 + 55 [bash]
  8,0    0       31     1.943770506  2261  Q   R 6184297 + 55 [bash]
  8,0    0       32     1.943772951  2261  F   R 6184297 + 55 [bash]
  8,0    0       33     1.943780843  2261  Q   R 6184462 + 55 [bash]
  8,0    0       34     1.943783776  2261  M   R 6184462 + 55 [bash]
  8,0    0       35     1.944444684     0 UT   N [swapper] 2
  8,0    0       36     1.944453624    10  U   N [kblockd/0] 2
  8,0    0       37     1.944470595    10  D   R 6184130 + 387 [kblockd/0]
  8,0    0       38     1.970340853     0  C   R 6184075 + 55 [0]
  8,0    0       39     1.973576739     0  C   R 6184130 + 387 [0]

Patches against Jens git to fix this.

---

block/blk-merge.c +0 -0
index 5efc9e7..44cc1d7 100644
@@ -395,9 +395,6 @@ static int ll_merge_requests_fn(struct request_queue *q, 

struct request *req,
if (blk_phys_contig_segment(q, req->biotail, next->bio))
total_phys_segments--;

- if (total_phys_segments > q->max_phys_segments)
- return 0;
-
total_hw_segments = req->nr_hw_segments + next->nr_hw_segments; if (blk_hw_contig_segment(q, req->biotail, next->bio)) {
int len = req->biotail->bi_hw_back_size +
@@ -415,6 +412,15 @@ static int ll_merge_requests_fn(struct request_queue *q, struct request *req,
if (total_hw_segments > q->max_hw_segments)
return 0;

+ /*
+ * FIXME: if 2 phys segments is used for a single hw segment?
+ */
+ if (total_phys_segments < total_hw_segments)
+ total_phys_segments = total_hw_segments;
+
+ if (total_phys_segments > q->max_phys_segments)
+ return 0;
+
/* Merge is OK... */ req->nr_phys_segments = total_phys_segments; req->nr_hw_segments = total_hw_segments;

But this may not be the complete fix? I am not sure whether the condition in FIXME comment can be triggered. The following patch may be a better fix.

---

block/blk-merge.c +0 -0
index 5efc9e7..b2c37f4 100644
@@ -467,6 +467,8 @@ static int attempt_merge(struct request_queue *q, struct 

request *req,

req->nr_sectors = req->hard_nr_sectors += next->hard_nr_sectors;

+ blk_recalc_rq_segments(req);
+
elv_merge_requests(q, req, next);

if (req->rq_disk) {

But still wouldn't it be incomplete fix as blk_recalc_rq_segments() can produce nr_phys_segments > q->max_phys_segments? Do we need something like this.

---

block/blk-merge.c +0 -0
index 5efc9e7..e4431db 100644
@@ -427,6 +427,8 @@ static int ll_merge_requests_fn(struct request_queue *q, 

struct request *req,
static int attempt_merge(struct request_queue *q, struct request *req,
struct request *next)
{
+ struct bio *req_biotail, *req_biotail_bi_next;
+
if (!rq_mergeable(req) || !rq_mergeable(next))
return 0;

@@ -462,11 +464,21 @@ static int attempt_merge(struct request_queue *q, struct request *req,
if (time_after(req->start_time, next->start_time))
req->start_time = next->start_time;

+ req_biotail = req->biotail;
+ req_biotail_bi_next = req->biotail->bi_next;
req->biotail->bi_next = next->bio;
req->biotail = next->biotail;

req->nr_sectors = req->hard_nr_sectors += next->hard_nr_sectors;

+ blk_recalc_rq_segments(req);
+ if (req->nr_phys_segments > q->max_phys_segments) {
+ req->biotail = req_biotail;
+ req->biotail->bi_next = req_biotail_bi_next;
+ blk_recalc_rq_segments(req);
+ return 0;
+ }
+
elv_merge_requests(q, req, next);

if (req->rq_disk) {

But blk_recalc_rq_segments() cannot increase nr_phys_segments by more than one. So checking for one lesser limit earlier should also work? But we would be mostly merging 1 lesser segment.

---

block/blk-merge.c +0 -0
index 5efc9e7..d9b5289 100644
@@ -256,7 +256,7 @@ static inline int ll_new_mergeable(struct request_queue 

*q,
{
int nr_phys_segs = bio_phys_segments(q, bio);

- if (req->nr_phys_segments + nr_phys_segs > q->max_phys_segments) {
+ if (req->nr_phys_segments + nr_phys_segs > q->max_phys_segments - 1) {
req->cmd_flags |= REQ_NOMERGE;
if (req == q->last_merge)
q->last_merge = NULL;
@@ -395,7 +395,7 @@ static int ll_merge_requests_fn(struct request_queue *q, struct request *req,
if (blk_phys_contig_segment(q, req->biotail, next->bio))
total_phys_segments--;

- if (total_phys_segments > q->max_phys_segments)
+ if (total_phys_segments > q->max_phys_segments - 1)
return 0;

total_hw_segments = req->nr_hw_segments + next->nr_hw_segments;
@@ -467,6 +467,8 @@ static int attempt_merge(struct request_queue *q, struct request *req,

req->nr_sectors = req->hard_nr_sectors += next->hard_nr_sectors;

+ blk_recalc_rq_segments(req);
+
elv_merge_requests(q, req, next);

if (req->rq_disk) {

Thanks
Nikanth Karthikesan

maintainer
#1 lore raw
Quoted 10 lines · Nikanth Karthikesan

This is a follow-up to my earlier mail http://lkml.org/lkml/2008/9/23/294
([PATCH] BUG: ll_merge_requests_fn() updates req->nr_phys_segments wrongly)

It is possible for the merging code to create lesser no of phys segments than hw segments, but every hw segment needs atleast one new phys segment. This triggers the BUG() on scsi_init_sgtable() as blk_rq_map_sg() returns more no of segments than rq->nr_phys_segments

The following blktrace shows a sequence of bio's to trigger such condition on my machine with max_sectors_kb=512 & max_hw_sectors_kb=32767.

Um, don't you mean this the other way around? I can see this problem occurring if the block layer gets tricked into doing a physical merge where sector limits forbid a virtual merge.

The bug would appear to be that we sometimes only look at q->max_sectors when deciding on mergability. Either we have to insist on max_sectors <= hw_max_sectors, or we have to start using min(q->max_sectors, q->max_hw_sectors) for this.

James

#2 lore raw
Quoted 4 lines · James Bottomley

The bug would appear to be that we sometimes only look at q->max_sectors when deciding on mergability. Either we have to insist on max_sectors <= hw_max_sectors, or we have to start using min(q->max_sectors, q->max_hw_sectors) for this.

q->max_sectors MUST always be <= q->max_hw_sectors, otherwise we could be sending down requests that are too large for the device to handle. So that condition would be a big bug. The sysfs interface checks for this, and blk_queue_max_sectors() makes sure that is true as well.

The fixes proposed still look weird. There is no phys vs hw segment constraints, the request must adhere to the limits set by both. It's mostly a moot point anyway, as 2.6.28 will get rid of the hw accounting anyway.

Signature · 1 line
Jens Axboe
maintainer
#3 lore raw
Quoted 10 lines · Jens Axboe
Quoted 4 lines · James Bottomley

The bug would appear to be that we sometimes only look at q->max_sectors when deciding on mergability. Either we have to insist on max_sectors <= hw_max_sectors, or we have to start using min(q->max_sectors, q->max_hw_sectors) for this.

q->max_sectors MUST always be <= q->max_hw_sectors, otherwise we could be sending down requests that are too large for the device to handle. So that condition would be a big bug. The sysfs interface checks for this, and blk_queue_max_sectors() makes sure that is true as well.

Yes, that seems always to be enforced. Perhaps there are other ways of tripping this problem ... I'm still sure if it occurs it's because we do a physical merge where a virtual merge is forbidden.

Quoted 4 lines

The fixes proposed still look weird. There is no phys vs hw segment constraints, the request must adhere to the limits set by both. It's mostly a moot point anyway, as 2.6.28 will get rid of the hw accounting anyway.

Agree all three proposed fixes look wrong. However, if it's what I think, just getting rid of hw accounting won't fix the problem because we'll still have the case where a physical merge is forbidden by iommu constraints ... this still needs to be accounted for.

What we really need is a demonstration of what actually is going wrong ...

James

#4 lore raw
Quoted 21 lines · James Bottomley
Quoted 10 lines · Jens Axboe
Quoted 4 lines · James Bottomley

The bug would appear to be that we sometimes only look at q->max_sectors when deciding on mergability. Either we have to insist on max_sectors <= hw_max_sectors, or we have to start using min(q->max_sectors, q->max_hw_sectors) for this.

q->max_sectors MUST always be <= q->max_hw_sectors, otherwise we could be sending down requests that are too large for the device to handle. So that condition would be a big bug. The sysfs interface checks for this, and blk_queue_max_sectors() makes sure that is true as well.

Yes, that seems always to be enforced. Perhaps there are other ways of tripping this problem ... I'm still sure if it occurs it's because we do a physical merge where a virtual merge is forbidden.

Quoted 4 lines

The fixes proposed still look weird. There is no phys vs hw segment constraints, the request must adhere to the limits set by both. It's mostly a moot point anyway, as 2.6.28 will get rid of the hw accounting anyway.

Quoted 7 lines

Agree all three proposed fixes look wrong. However, if it's what I think, just getting rid of hw accounting won't fix the problem because we'll still have the case where a physical merge is forbidden by iommu constraints ... this still needs to be accounted for.

What we really need is a demonstration of what actually is going wrong ...

Yep, IIRC we both asked for that the last time as well... Nikanth?

Signature · 1 line
Jens Axboe
#5 lore raw
Quoted 22 lines · On Thursday 02 October 2008 22:43:57 Jens Axboe wrote:
Quoted 21 lines · James Bottomley
Quoted 10 lines · Jens Axboe
Quoted 4 lines · James Bottomley

The bug would appear to be that we sometimes only look at q->max_sectors when deciding on mergability. Either we have to insist on max_sectors <= hw_max_sectors, or we have to start using min(q->max_sectors, q->max_hw_sectors) for this.

q->max_sectors MUST always be <= q->max_hw_sectors, otherwise we could be sending down requests that are too large for the device to handle. So that condition would be a big bug. The sysfs interface checks for this, and blk_queue_max_sectors() makes sure that is true as well.

Yes, that seems always to be enforced. Perhaps there are other ways of tripping this problem ... I'm still sure if it occurs it's because we do a physical merge where a virtual merge is forbidden.

Quoted 4 lines

The fixes proposed still look weird. There is no phys vs hw segment constraints, the request must adhere to the limits set by both. It's mostly a moot point anyway, as 2.6.28 will get rid of the hw accounting anyway.

Quoted 5 lines
Quoted 5 lines

Agree all three proposed fixes look wrong. However, if it's what I think, just getting rid of hw accounting won't fix the problem because we'll still have the case where a physical merge is forbidden by iommu constraints ... this still needs to be accounted for.

Yes. This patch fixes it.

---

block/blk-merge.c +0 -0
index 5efc9e7..9c2fe49 100644
@@ -392,7 +392,11 @@ static int ll_merge_requests_fn(struct request_queue *q, 

struct request *req,
return 0;

total_phys_segments = req->nr_phys_segments + next->nr_phys_segments;
- if (blk_phys_contig_segment(q, req->biotail, next->bio))
+ if (blk_phys_contig_segment(q, req->biotail, next->bio) &&
+ BIOVEC_VIRT_MERGEABLE(__BVEC_END(req->biotail),
+ __BVEC_START(next->bio)) &&
+ !BIOVEC_VIRT_OVERSIZE(req->biotail->bi_hw_back_size
+ + next->bio->bi_hw_front_size))
total_phys_segments--;

if (total_phys_segments > q->max_phys_segments)

Quoted 4 lines
Quoted 2 lines

What we really need is a demonstration of what actually is going wrong ...

Yep, IIRC we both asked for that the last time as well... Nikanth?

Sorry, I had already sent the blktrace and some code snippet that would reproduce the condition. Here is the module and user-space program that can trigger this condition.

diskbiomod.c
---

#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/blkdev.h>
#include <linux/miscdevice.h>
/*
** Shared between the driver module and application. */
#define MOD_NODE "/dev/DiskBio"
#define MOD_NAME "DiskBio"

/*
** IOCTLs
*/
#define DB_IOCTL_DISK 0x00000001
#define DB_IOCTL_GENDISK 0x00000002

/*
** MODULE Defines.
*/
MODULE_DESCRIPTION("DiskBio - Initiate Disk I/O Traffic"); MODULE_LICENSE("GPL");

/*
** Module Defines.
*/
#define MOD_VERSION "09-11-2008-1"
#define NUM_BIO 8
#define NUMBER_OF_VECS 16
#define START_LBA 0x5e5c8b

/*
** Module Globals.
*/
static struct gendisk *(*get_GenDisk)(dev_t, int *) = NULL;
static int ErrorsOccurred = 0;

typedef struct {
	int	IoSize;
	char	*Mem;
} DB_MEM_LIST, *pDB_MEM_LIST;
DB_MEM_LIST	dbMemList[NUM_BIO] = {
	{ 0x6e00,	NULL },
	{ 0x6e00,	NULL },
	{ 0x7000,	NULL },
	{ 0x7000,	NULL },
	{ 0x6e00,	NULL },
	{ 0x6e00,	NULL },
	{ 0x6e00,	NULL },
	{ 0x6e00,	NULL },
};

/*
** Wait Queue.
*/
DECLARE_WAIT_QUEUE_HEAD(db_wait_queue);

/*
** db_end_io()
*/
static void/*int*/
db_end_io(struct bio *Bio,/* unsigned int Bytes_Done,*/ int Error)

{
	static int Completions = 0;

	if(Error) {
		++ErrorsOccurred;
		printk("%s: End_Io Error=0x%x\n", MOD_NAME, Error);
	}
	if(Bio->bi_size) {
		++ErrorsOccurred;
		printk("%s: End_Io bi_size=0x%x\n", MOD_NAME, Bio->bi_size);
	}

	if(++Completions < NUM_BIO) {
		return;//(0);
	}
	Completions = 0;

	wake_up(&db_wait_queue);
	return;//(0);
} /* end - db_end_io() */

/*
** db_do_io()
*/
static int
db_do_io(struct gendisk *GD)

{
	int			Loop;
	int			RC			= 0;
	struct bio		*BioList[NUM_BIO]	= { NULL };
	struct bio		*Bio			= NULL;
	struct block_device	*Bdev;
	long			Sector;

	/*
	** Get block device structure.
	*/
	Bdev = bdget_disk(GD, 0);
	if(!Bdev) {
		RC = -ENOMEM;
		goto OutOfHere;
	}

	/*
	** Allocate BIOs.
	*/
	for(Loop = 0; Loop < NUM_BIO; Loop++) {
		BioList[Loop] = bio_alloc(GFP_KERNEL, NUMBER_OF_VECS);
		if(!BioList[Loop]) {
			RC = -ENOMEM;
			goto OutOfHere;
		}
	}

	/*
	** Initialize the I/O.
	*/
	Sector = START_LBA;
	for(Loop = 0; Loop < NUM_BIO; Loop++) {
		Bio = BioList[Loop];
		Bio->bi_sector			= Sector;
		Bio->bi_bdev			= Bdev;
		Bio->bi_end_io			= db_end_io;
		if (Loop == 0) {
			if (!bio_add_page(BioList[Loop],
					virt_to_page(dbMemList[Loop].Mem),
					0x3000,
					offset_in_page(dbMemList[Loop].Mem))) {
				printk("bio add page failed- %dA\n", Loop);
			}
			if (!bio_add_page(BioList[Loop],
					virt_to_page(dbMemList[7].Mem),
					0x3e00,
					offset_in_page(dbMemList[7].Mem))) {
				printk("bio add page failed- %dB\n", Loop);
			}
		} else if (Loop == 7) {
			if (!bio_add_page(BioList[Loop],
					virt_to_page(dbMemList[Loop].Mem),
					0x2000,
					offset_in_page(dbMemList[Loop].Mem))) {
				printk("bio add page failed- %dA\n", Loop);
			}
			if (!bio_add_page(BioList[Loop],
					virt_to_page(dbMemList[7].Mem),
					0x4e00,
					offset_in_page(dbMemList[7].Mem))) {
				printk("bio add page failed- %dB\n", Loop);
			}
		} else if (!bio_add_page(BioList[Loop],
					virt_to_page(dbMemList[Loop].Mem),
					dbMemList[Loop].IoSize,
					offset_in_page(dbMemList[Loop].Mem))) {
			printk("bio add page failed %d\n", Loop);
		}
		Sector += (Bio->bi_size / 512);
	}
	ErrorsOccurred = 0;

	/*
	** Issue the I/Os.
	*/
	submit_bio(READ, BioList[0]);	// 1
	submit_bio(READ, BioList[1]);	// 2
	submit_bio(READ, BioList[3]);	// 4
	submit_bio(READ, BioList[2]);	// 3
	submit_bio(READ, BioList[5]);	// 6
	submit_bio(READ, BioList[6]);	// 7
	submit_bio(READ, BioList[4]);	// 5
	submit_bio(READ, BioList[7]);	// 8

	/*
	** Wait for the completion.
	*/
	sleep_on(&db_wait_queue);

	/*
	** Release the resources.
	*/
OutOfHere:
	for(Loop = 0; Loop < NUM_BIO; Loop++) {
		if(BioList[Loop]) bio_put(BioList[Loop]);
	}
	if(ErrorsOccurred)
		RC = -EIO;
	
	return(RC);
} /* end - db_do_io() */

/*
** db_ioctl
*/
static int
db_ioctl(struct inode *inode, struct file *file, uint Command, ulong Arg)

{
	int		Status	= 0;
	struct gendisk	*GenDisk;
	int		Part;
	char		*Mem0	= NULL;
	char		*Mem1	= NULL;
	char		*Mem2	= NULL;
	char		*Mem5	= NULL;
	char		*Mem6	= NULL;
	char		*Mem7	= NULL;

	switch(Command) {
	case DB_IOCTL_GENDISK:
		get_GenDisk = (void *)Arg;
		break;

	case DB_IOCTL_DISK:
		Arg = new_decode_dev(Arg);
		if(!get_GenDisk) {
			Status = -EADDRNOTAVAIL;
			break;
		}
		GenDisk = get_GenDisk(Arg, &Part);
		if(!GenDisk) {
			Status = -ENODEV;
			break;
		}

		/*
		** Allocate Memory.
		*/
		Mem0 = kmalloc(dbMemList[0].IoSize, GFP_KERNEL);
		Mem1 = kmalloc(dbMemList[1].IoSize, GFP_KERNEL);
		Mem2 = kmalloc((dbMemList[2].IoSize + dbMemList[3].IoSize + 
dbMemList[4].IoSize), GFP_KERNEL);
		Mem5 = kmalloc(dbMemList[5].IoSize, GFP_KERNEL);
		Mem6 = kmalloc(dbMemList[6].IoSize, GFP_KERNEL);
		Mem7 = kmalloc(dbMemList[7].IoSize, GFP_KERNEL);

		if(!Mem0 || !Mem1 || !Mem2 || !Mem5 || !Mem6 || !Mem7) {
			Status = -ENOMEM;
			goto OutOfHere2;
		}

		dbMemList[0].Mem = Mem0;
		dbMemList[1].Mem = Mem1;
		dbMemList[2].Mem = Mem2;
		dbMemList[3].Mem = dbMemList[2].Mem + dbMemList[2].IoSize;
		dbMemList[4].Mem = dbMemList[3].Mem + dbMemList[3].IoSize;
		dbMemList[5].Mem = Mem5;
		dbMemList[6].Mem = Mem6;
		dbMemList[7].Mem = Mem7;

		Status = db_do_io(GenDisk);

OutOfHere2:

		if(Mem0) kfree(Mem0);
		if(Mem1) kfree(Mem1);
		if(Mem2) kfree(Mem2);
		if(Mem5) kfree(Mem5);
		if(Mem6) kfree(Mem6);
		if(Mem7) kfree(Mem7);
		break;

	default:
		printk("%s: Unknown Ioctl Command (0x%x)\n.", MOD_NAME, Command);
		Status = -EINVAL;
		break;
	}

	return(Status);
} /* end db_ioctl() */

/*
** File operations structure.
*/

static struct file_operations	db_fops = {
	.owner		= THIS_MODULE,
	.ioctl		= db_ioctl,
};

/*
** Misc Device structure.
*/

static struct miscdevice db_miscdev = {
	MISC_DYNAMIC_MINOR,
	MOD_NAME,
	&db_fops,
};

/*
** db_init()
*/
int __init
db_init(void)

{
	int	Error = 0;

	printk("%s: Init: ENTER.\n", MOD_NAME);
	printk("%s: Version %s.\n", MOD_NAME, MOD_VERSION);

	Error = misc_register(&db_miscdev);
	if(Error)
		printk("%s: Misc Register Failure!\n", MOD_NAME);
	
	printk("%s: Init: DONE.\n", MOD_NAME);
	return(Error);
} /* end - db_init() */

/*
** db_exit()
*/
void __exit
db_exit(void)

{
	printk("%s: Exit: ENTER.\n", MOD_NAME);

	misc_deregister(&db_miscdev);
		
	printk("%s: Exit: DONE.\n", MOD_NAME);
} /* end - db_exit() */

/*
** Module Entry Points.
*/
module_init(db_init);
module_exit(db_exit);

---
The Userspace utility to send ioctl to the module. diskbio.c
---

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <libgen.h>
/*
** Shared between the driver module and application. */
#define MOD_NODE "/dev/DiskBio"
#define MOD_NAME "DiskBio"

/*
** IOCTLs
*/
#define DB_IOCTL_DISK 0x00000001
#define DB_IOCTL_GENDISK 0x00000002

#define DEVICE_BUF_SIZE 100
#define GET_GENDISK "get_gendisk"

int
OpenNode(void)

{
	int		IoPtr;
	FILE		*Fd;
	char		Buf[DEVICE_BUF_SIZE];
	unsigned long	Symbol_get_gendisk	= 0;

	/*
	** Get the symbols we need so they can be sent to the driver.
	*/
	if((Fd = fopen("/proc/kallsyms", "r")) == NULL) {
		perror("open");
		fprintf(stderr, "Can Not Get Symbol Values!\n");
		return(-1);
	}

	/*
	** Scan the /proc/kallsyms file for the symbols and addresses.
	*/
	while(fgets(Buf, DEVICE_BUF_SIZE, Fd)) {
		unsigned long	SymbolAddress;
		char		Tag[DEVICE_BUF_SIZE];
		char		Name[DEVICE_BUF_SIZE];

		if(sscanf(Buf, "%lx %s %s", &SymbolAddress, Tag, Name) != 3)
			continue;

		/*
		** Check for a symbol match.
		*/
		if(!strcmp(Name, GET_GENDISK)) {
			Symbol_get_gendisk = SymbolAddress;
			break;
		}
	}

	/*
	** Done with this file.
	*/
	fclose(Fd);

	/*
	** Make sure we found all of the symbols.
	*/
	if(!Symbol_get_gendisk) {
		fprintf(stderr, "%s Symbol NOT Found!\n", GET_GENDISK);
		return(-1);
	}

	/*
	** Device node should be present. Try and open.
	*/
	if((IoPtr = open(MOD_NODE, O_RDWR)) == -1) {
		perror("open");
		fprintf(stderr, "Can Not Open Module Device '%s'!\n", MOD_NODE);
		fprintf(stderr, "Unload and Reload the Module.\n");
		return(-1);
	}

	/*
	** Send the symbol addresses to the module.
	*/
	if(ioctl(IoPtr, DB_IOCTL_GENDISK, Symbol_get_gendisk)) {
		perror("ioctl");
		fprintf(stderr, "Unable to Send GENDISK Symbol to Module!\n");
		close(IoPtr);
		return(-1);
	}

	return(IoPtr);
}

int
main(int argc, char *argv[])

{
	int		RC		= 0;
	int		IoPtr		= 0;
	int		DevPtr		= 0;
	unsigned long	DeviceNumber;
	struct stat	StatBuf;

	/*
	** Check Arguments.
	*/
	if(argc < 2) {
		fprintf(stderr, "Usage: %s /dev/sdX\n", basename(argv[0]));
		exit(1);
	}

	/*
	** Open the device node to the driver interface.
	*/
	if((IoPtr = OpenNode()) == -1) {
		exit(2);
	}

	/*
	** Open the device.
	*/
	DevPtr = open(argv[1], O_RDWR);
	if(DevPtr == -1) {
		perror("open");
		fprintf(stderr, "Open Failed for Device '%s'\n", argv[1]);
		RC = 3;
		goto out;
	}

	/*
	** Make sure the device is a block device.
	*/
	if(fstat(DevPtr, &StatBuf)) {
		perror("fstat");
		fprintf(stderr, "Unable to stat device '%s'.\n", argv[1]);
		RC=4;
		goto out;
	}
	if(!S_ISBLK(StatBuf.st_mode)) {
		fprintf(stderr, "Device '%s' not a block device.\n", argv[1]);
		RC = 5;
		goto out;
	}

	/*
	** Get Device Number.
	*/
	DeviceNumber = StatBuf.st_rdev;

	/*
	** Send the device number to the driver
	** so it can do an I/O for us.
	*/
	RC = ioctl(IoPtr, DB_IOCTL_DISK, DeviceNumber);
	if(RC) {
		perror("ioctl");
		fprintf(stderr, "Ioctl Failed (%d).\n", RC);
	}

out:

	if(DevPtr > -1)	close(DevPtr);
	if(IoPtr > -1)	close(IoPtr);
	exit(RC);
}

Thanks
Nikanth Karthikesan

#6 lore raw
In reply to Jens Axboe
Quoted 27 lines · On Thu, 2 Oct 2008 19:13:57 +0200 Jens Axboe <[email protected]> wrote:
Quoted 26 lines · James Bottomley
Quoted 10 lines · Jens Axboe
Quoted 4 lines · James Bottomley

The bug would appear to be that we sometimes only look at q->max_sectors when deciding on mergability. Either we have to insist on max_sectors <= hw_max_sectors, or we have to start using min(q->max_sectors, q->max_hw_sectors) for this.

q->max_sectors MUST always be <= q->max_hw_sectors, otherwise we could be sending down requests that are too large for the device to handle. So that condition would be a big bug. The sysfs interface checks for this, and blk_queue_max_sectors() makes sure that is true as well.

Yes, that seems always to be enforced. Perhaps there are other ways of tripping this problem ... I'm still sure if it occurs it's because we do a physical merge where a virtual merge is forbidden.

Quoted 4 lines

The fixes proposed still look weird. There is no phys vs hw segment constraints, the request must adhere to the limits set by both. It's mostly a moot point anyway, as 2.6.28 will get rid of the hw accounting anyway.

Agree all three proposed fixes look wrong. However, if it's what I think, just getting rid of hw accounting won't fix the problem because we'll still have the case where a physical merge is forbidden by iommu constraints ... this still needs to be accounted for.

Quoted 4 lines
Quoted 2 lines

What we really need is a demonstration of what actually is going wrong ...

Yep, IIRC we both asked for that the last time as well... Nikanth?

Possibly, blk_phys_contig_segment might miscalculate q->max_segment_size?

blk_phys_contig_segment does:

req->biotail->bi_size + next_req->bio->bi_size > q->max_segment_size;

But it's possible that req->biotail and the previous bio are supposed be merged into one segment? Then we could create too large segment here.

#7 lore raw
Quoted 38 lines · FUJITA Tomonori
Quoted 27 lines · On Thu, 2 Oct 2008 19:13:57 +0200 Jens Axboe <[email protected]> wrote:
Quoted 26 lines · James Bottomley
Quoted 10 lines · Jens Axboe
Quoted 4 lines · James Bottomley

The bug would appear to be that we sometimes only look at q->max_sectors when deciding on mergability. Either we have to insist on max_sectors <= hw_max_sectors, or we have to start using min(q->max_sectors, q->max_hw_sectors) for this.

q->max_sectors MUST always be <= q->max_hw_sectors, otherwise we could be sending down requests that are too large for the device to handle. So that condition would be a big bug. The sysfs interface checks for this, and blk_queue_max_sectors() makes sure that is true as well.

Yes, that seems always to be enforced. Perhaps there are other ways of tripping this problem ... I'm still sure if it occurs it's because we do a physical merge where a virtual merge is forbidden.

Quoted 4 lines

The fixes proposed still look weird. There is no phys vs hw segment constraints, the request must adhere to the limits set by both. It's mostly a moot point anyway, as 2.6.28 will get rid of the hw accounting anyway.

Agree all three proposed fixes look wrong. However, if it's what I think, just getting rid of hw accounting won't fix the problem because we'll still have the case where a physical merge is forbidden by iommu constraints ... this still needs to be accounted for.

Quoted 4 lines
Quoted 2 lines

What we really need is a demonstration of what actually is going wrong ...

Yep, IIRC we both asked for that the last time as well... Nikanth?

Possibly, blk_phys_contig_segment might miscalculate q->max_segment_size?

Quoted 7 lines

blk_phys_contig_segment does:

req->biotail->bi_size + next_req->bio->bi_size > q->max_segment_size;

But it's possible that req->biotail and the previous bio are supposed be merged into one segment? Then we could create too large segment here.

Hmm yes, that looks like it could indeed be a problem! We could fix this with similar logic to what we used to do for the hw merging, keep track of the current segment size that this bio belongs to, so it would end up ala

        if (blk_phys_contig_segment(q, req->biotail, next->bio) &&
            rq->biotail->bi_seg_size + next->bio->bi_size <= q->max_segment_size) {
                total_phys_segments--;
                next->bio->bi_seg_size = rq->biotail->bi_seg_size + next->bio->bi_size;
        }

for the merge part.

Signature · 1 line
Jens Axboe
#8 lore raw
Quoted 41 lines · On Fri, 10 Oct 2008 14:03:44 +0200 Jens Axboe <[email protected]> wrote:
Quoted 40 lines · FUJITA Tomonori
Quoted 27 lines · On Thu, 2 Oct 2008 19:13:57 +0200 Jens Axboe <[email protected]> wrote:
Quoted 26 lines · James Bottomley
Quoted 10 lines · Jens Axboe
Quoted 4 lines · James Bottomley

The bug would appear to be that we sometimes only look at q->max_sectors when deciding on mergability. Either we have to insist on max_sectors <= hw_max_sectors, or we have to start using min(q->max_sectors, q->max_hw_sectors) for this.

q->max_sectors MUST always be <= q->max_hw_sectors, otherwise we could be sending down requests that are too large for the device to handle. So that condition would be a big bug. The sysfs interface checks for this, and blk_queue_max_sectors() makes sure that is true as well.

Yes, that seems always to be enforced. Perhaps there are other ways of tripping this problem ... I'm still sure if it occurs it's because we do a physical merge where a virtual merge is forbidden.

Quoted 4 lines

The fixes proposed still look weird. There is no phys vs hw segment constraints, the request must adhere to the limits set by both. It's mostly a moot point anyway, as 2.6.28 will get rid of the hw accounting anyway.

Agree all three proposed fixes look wrong. However, if it's what I think, just getting rid of hw accounting won't fix the problem because we'll still have the case where a physical merge is forbidden by iommu constraints ... this still needs to be accounted for.

Quoted 4 lines
Quoted 2 lines

What we really need is a demonstration of what actually is going wrong ...

Yep, IIRC we both asked for that the last time as well... Nikanth?

Possibly, blk_phys_contig_segment might miscalculate q->max_segment_size?

blk_phys_contig_segment does:

Quoted 7 lines
Quoted 5 lines

req->biotail->bi_size + next_req->bio->bi_size > q->max_segment_size;

But it's possible that req->biotail and the previous bio are supposed be merged into one segment? Then we could create too large segment here.

Hmm yes, that looks like it could indeed be a problem!

I think so.

Quoted 4 lines

We could fix this
with similar logic to what we used to do for the hw merging, keep track of the current segment size that this bio belongs to, so it would end up ala

Yeah, exactly.

You want a fix for this 2.6.28? Or disable this feature for 2.6.28?

Quoted 7 lines
        if (blk_phys_contig_segment(q, req->biotail, next->bio) &&
            rq->biotail->bi_seg_size + next->bio->bi_size <= q->max_segment_size) {
                total_phys_segments--;
                next->bio->bi_seg_size = rq->biotail->bi_seg_size + next->bio->bi_size;
        }

for the merge part.

#9 lore raw
Quoted 55 lines · FUJITA Tomonori
Quoted 41 lines · On Fri, 10 Oct 2008 14:03:44 +0200 Jens Axboe <[email protected]> wrote:
Quoted 40 lines · FUJITA Tomonori
Quoted 27 lines · On Thu, 2 Oct 2008 19:13:57 +0200 Jens Axboe <[email protected]> wrote:
Quoted 26 lines · James Bottomley
Quoted 10 lines · Jens Axboe
Quoted 4 lines · James Bottomley

The bug would appear to be that we sometimes only look at q->max_sectors when deciding on mergability. Either we have to insist on max_sectors <= hw_max_sectors, or we have to start using min(q->max_sectors, q->max_hw_sectors) for this.

q->max_sectors MUST always be <= q->max_hw_sectors, otherwise we could be sending down requests that are too large for the device to handle. So that condition would be a big bug. The sysfs interface checks for this, and blk_queue_max_sectors() makes sure that is true as well.

Yes, that seems always to be enforced. Perhaps there are other ways of tripping this problem ... I'm still sure if it occurs it's because we do a physical merge where a virtual merge is forbidden.

Quoted 4 lines

The fixes proposed still look weird. There is no phys vs hw segment constraints, the request must adhere to the limits set by both. It's mostly a moot point anyway, as 2.6.28 will get rid of the hw accounting anyway.

Agree all three proposed fixes look wrong. However, if it's what I think, just getting rid of hw accounting won't fix the problem because we'll still have the case where a physical merge is forbidden by iommu constraints ... this still needs to be accounted for.

Quoted 4 lines
Quoted 2 lines

What we really need is a demonstration of what actually is going wrong ...

Yep, IIRC we both asked for that the last time as well... Nikanth?

Possibly, blk_phys_contig_segment might miscalculate q->max_segment_size?

blk_phys_contig_segment does:

Quoted 7 lines
Quoted 5 lines

req->biotail->bi_size + next_req->bio->bi_size > q->max_segment_size;

But it's possible that req->biotail and the previous bio are supposed be merged into one segment? Then we could create too large segment here.

Hmm yes, that looks like it could indeed be a problem!

I think so.

Quoted 8 lines
Quoted 4 lines

We could fix this
with similar logic to what we used to do for the hw merging, keep track of the current segment size that this bio belongs to, so it would end up ala

Yeah, exactly.

You want a fix for this 2.6.28? Or disable this feature for 2.6.28?

Lets fix it. It wont be part of the initial merge, since it'll need some dedicated testing, but we can get it there for 2.6.28. Shall I interpret your message as willingness to write up the fix? :)

Signature · 1 line
Jens Axboe
#10 lore raw
Quoted 61 lines · On Fri, 10 Oct 2008 14:37:19 +0200 Jens Axboe <[email protected]> wrote:
Quoted 60 lines · FUJITA Tomonori
Quoted 41 lines · On Fri, 10 Oct 2008 14:03:44 +0200 Jens Axboe <[email protected]> wrote:
Quoted 40 lines · FUJITA Tomonori
Quoted 27 lines · On Thu, 2 Oct 2008 19:13:57 +0200 Jens Axboe <[email protected]> wrote:
Quoted 26 lines · James Bottomley
Quoted 10 lines · Jens Axboe
Quoted 4 lines · James Bottomley

The bug would appear to be that we sometimes only look at q->max_sectors when deciding on mergability. Either we have to insist on max_sectors <= hw_max_sectors, or we have to start using min(q->max_sectors, q->max_hw_sectors) for this.

q->max_sectors MUST always be <= q->max_hw_sectors, otherwise we could be sending down requests that are too large for the device to handle. So that condition would be a big bug. The sysfs interface checks for this, and blk_queue_max_sectors() makes sure that is true as well.

Yes, that seems always to be enforced. Perhaps there are other ways of tripping this problem ... I'm still sure if it occurs it's because we do a physical merge where a virtual merge is forbidden.

Quoted 4 lines

The fixes proposed still look weird. There is no phys vs hw segment constraints, the request must adhere to the limits set by both. It's mostly a moot point anyway, as 2.6.28 will get rid of the hw accounting anyway.

Agree all three proposed fixes look wrong. However, if it's what I think, just getting rid of hw accounting won't fix the problem because we'll still have the case where a physical merge is forbidden by iommu constraints ... this still needs to be accounted for.

Quoted 4 lines
Quoted 2 lines

What we really need is a demonstration of what actually is going wrong ...

Yep, IIRC we both asked for that the last time as well... Nikanth?

Possibly, blk_phys_contig_segment might miscalculate q->max_segment_size?

blk_phys_contig_segment does:

Quoted 7 lines
Quoted 5 lines

req->biotail->bi_size + next_req->bio->bi_size > q->max_segment_size;

But it's possible that req->biotail and the previous bio are supposed be merged into one segment? Then we could create too large segment here.

Hmm yes, that looks like it could indeed be a problem!

I think so.

Quoted 4 lines

We could fix this
with similar logic to what we used to do for the hw merging, keep track of the current segment size that this bio belongs to, so it would end up ala

Quoted 7 lines
Quoted 3 lines

Yeah, exactly.

You want a fix for this 2.6.28? Or disable this feature for 2.6.28?

Lets fix it. It wont be part of the initial merge, since it'll need some dedicated testing, but we can get it there for 2.6.28. Shall I interpret your message as willingness to write up the fix? :)

Yeah, it's on this weekend todo list. :) I want to look at the code again and make sure I correctly understand the problem.

#11 lore raw
In reply to Nikanth Karthikesan
Quoted 31 lines · On Thursday 02 October 2008 19:59:33 Nikanth Karthikesan wrote:

This is a follow-up to my earlier mail http://lkml.org/lkml/2008/9/23/294
([PATCH] BUG: ll_merge_requests_fn() updates req->nr_phys_segments wrongly)

It is possible for the merging code to create lesser no of phys segments than hw segments, but every hw segment needs atleast one new phys segment. This triggers the BUG() on scsi_init_sgtable() as blk_rq_map_sg() returns more no of segments than rq->nr_phys_segments

The following blktrace shows a sequence of bio's to trigger such condition on my machine with max_sectors_kb=512 & max_hw_sectors_kb=32767.

  8,0    0       12     1.943680621  2261  Q   R 6184075 + 55 [bash]
  8,0    0       13     1.943684671  2261  G   R 6184075 + 55 [bash]
  8,0    0       14     1.943690189  2261  P   N [bash]
  8,0    0       15     1.943692075  2261  I   R 6184075 + 55 [bash]
  8,0    0       16     1.943712119  2261  D   R 6184075 + 55 [bash]
  8,0    0       17     1.943718684  2261  Q   R 6184130 + 55 [bash]
  8,0    0       18     1.943721897  2261  G   R 6184130 + 55 [bash]
  8,0    0       19     1.943726576  2261  P   N [bash]
  8,0    0       20     1.943727763  2261  I   R 6184130 + 55 [bash]
  8,0    0       21     1.943731675  2261  Q   R 6184241 + 56 [bash]
  8,0    0       22     1.943735167  2261  G   R 6184241 + 56 [bash]
  8,0    0       23     1.943739497  2261  I   R 6184241 + 56 [bash]
  8,0    0       24     1.943742081  2261  Q   R 6184185 + 56 [bash]
  8,0    0       25     1.943744875  2261  M   R 6184185 + 56 [bash]
  8,0    0       26     1.943753535  2261  Q   R 6184352 + 55 [bash]
  8,0    0       27     1.943756538  2261  G   R 6184352 + 55 [bash]
  8,0    0       28     1.943760868  2261  I   R 6184352 + 55 [bash]
  8,0    0       29     1.943763522  2261  Q   R 6184407 + 55 [bash]
  8,0    0       30     1.943766316  2261  M   R 6184407 + 55 [bash]
  8,0    0       31     1.943770506  2261  Q   R 6184297 + 55 [bash]
Quoted 10 lines
  8,0    0       32     1.943772951  2261  F   R 6184297 + 55 [bash]
  8,0    0       33     1.943780843  2261  Q   R 6184462 + 55 [bash]
  8,0    0       34     1.943783776  2261  M   R 6184462 + 55 [bash]
  8,0    0       35     1.944444684     0 UT   N [swapper] 2
  8,0    0       36     1.944453624    10  U   N [kblockd/0] 2
  8,0    0       37     1.944470595    10  D   R 6184130 + 387 [kblockd/0]
  8,0    0       38     1.970340853     0  C   R 6184075 + 55 [0]
  8,0    0       39     1.973576739     0  C   R 6184130 + 387 [0]

Oops, that was incomplete information to reproduce the issue.

typedef struct {
	int	IoSize;
	char	*Mem;
} DB_MEM_LIST, *pDB_MEM_LIST;
DB_MEM_LIST	dbMemList[NUM_BIO] = {
	{ 0x6e00,	NULL },
	{ 0x6e00,	NULL },
	{ 0x7000,	NULL },
	{ 0x7000,	NULL },
	{ 0x6e00,	NULL },
	{ 0x6e00,	NULL },
	{ 0x6e00,	NULL },
	{ 0x6e00,	NULL },
};

// Allocate Memory.
char *Mem0 = kmalloc(dbMemList[0].IoSize, GFP_KERNEL); char *Mem1 = kmalloc(dbMemList[1].IoSize, GFP_KERNEL); char *Mem2 = kmalloc((dbMemList[2].IoSize + dbMemList[3].IoSize + dbMemList[4].IoSize), GFP_KERNEL);
char *Mem5 = kmalloc(dbMemList[5].IoSize, GFP_KERNEL); char *Mem6 = kmalloc(dbMemList[6].IoSize, GFP_KERNEL); char *Mem7 = kmalloc(dbMemList[7].IoSize, GFP_KERNEL);

dbMemList[0].Mem = Mem0;
dbMemList[1].Mem = Mem1;
dbMemList[2].Mem = Mem2;
dbMemList[3].Mem = dbMemList[2].Mem + dbMemList[2].IoSize; dbMemList[4].Mem = dbMemList[3].Mem + dbMemList[3].IoSize; dbMemList[5].Mem = Mem5;
dbMemList[6].Mem = Mem6;
dbMemList[7].Mem = Mem7;

int Loop;
struct bio *BioList[NUM_BIO] = { NULL };
struct bio *Bio = NULL;
long Sector;

/*
** Allocate BIOs.
*/
for(Loop = 0; Loop < NUM_BIO; Loop++)

	BioList[Loop] = bio_alloc(GFP_KERNEL, NUMBER_OF_VECS);
for(Loop = 0; Loop < NUM_BIO; Loop++) {
	Bio = BioList[Loop];
	Bio->bi_sector			= Sector;
	Bio->bi_bdev			= Bdev;
	Bio->bi_end_io			= db_end_io;
	if (Loop == 0) {
		if (!bio_add_page(BioList[Loop],
				virt_to_page(dbMemList[Loop].Mem),
				0x3000,
				offset_in_page(dbMemList[Loop].Mem))) {
			printk("NIK: bio add page failed- %dA\n", Loop);
		}
		if (!bio_add_page(BioList[Loop],
				virt_to_page(dbMemList[7].Mem),
				0x3e00,
				offset_in_page(dbMemList[7].Mem))) {
			printk("NIK: bio add page failed- %dB\n", Loop);
		}
	} else if (Loop == 7) {
		if (!bio_add_page(BioList[Loop],
				virt_to_page(dbMemList[Loop].Mem),
				0x2000,
				offset_in_page(dbMemList[Loop].Mem))) {
			printk("NIK: bio add page failed- %dA\n", Loop);
		}
		if (!bio_add_page(BioList[Loop],
				virt_to_page(dbMemList[7].Mem),
				0x4e00,
				offset_in_page(dbMemList[7].Mem))) {
			printk("NIK: bio add page failed- %dB\n", Loop);
		}
	} else if (!bio_add_page(BioList[Loop],
				virt_to_page(dbMemList[Loop].Mem),
				dbMemList[Loop].IoSize,
				offset_in_page(dbMemList[Loop].Mem))) {
		printk("NIK: bio add page failed %d\n", Loop);
	}
	Sector += (Bio->bi_size / 512);
}

submit_bio(READ, BioList[0]); // 1
submit_bio(READ, BioList[1]); // 2
submit_bio(READ, BioList[3]); // 4
submit_bio(READ, BioList[2]); // 3
submit_bio(READ, BioList[5]); // 6
submit_bio(READ, BioList[6]); // 7
submit_bio(READ, BioList[4]); // 5
submit_bio(READ, BioList[7]); // 8

Thanks
Nikanth Karthikesan