linux-kernel - Re: disk statistics issue in 2.6.27

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1225748352.15785.5.camel@localhost.localdomain>
Date:	Mon, 03 Nov 2008 22:39:12 +0100
From:	Miquel van Smoorenburg <mikevs@...all.net>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
	mikevs@...all.net
Subject: Re: disk statistics issue in 2.6.27

On Fri, 2008-10-31 at 13:47 +0100, Jens Axboe wrote:
> On Thu, Oct 23 2008, Miquel van Smoorenburg wrote:
>
> > I added some debug statements to block/blk-core.c, and it appears that
> > blk_end_io() is always called with nr_bytes == 16320 Kbytes (16711680).
> > 
> > Ofcourse I should have noticed earlier that iostat -x 2 always prints
> > 32640 as "average request size" (in sectors).
> 
> You didn't happen to log a backtrace from that, did you? That's a weird
> nr_bytes, it's 0xff0000.
> 
> I'm assuming this then fixes it, just wondering what the heck is going
> on here.
> 
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 33c8d4b..a372618 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -1712,11 +1710,12 @@ static int __end_that_request_first(struct request *req, int error,
>  	if (blk_fs_request(req) && req->rq_disk) {
>  		const int rw = rq_data_dir(req);
>  		struct hd_struct *part;
> -		int cpu;
> +		int cpu, sectors;
>  
> +		sectors = min_t(int, nr_bytes >> 9, req->hard_nr_sectors);
>  		cpu = part_stat_lock();
>  		part = disk_map_sector_rcu(req->rq_disk, req->sector);
> -		part_stat_add(cpu, part, sectors[rw], nr_bytes >> 9);
> +		part_stat_add(cpu, part, sectors[rw], sectors);
>  		part_stat_unlock();
>  	}

I didn't try the above patch yet (it might work), but I did find the
cause. I bisected the problem and it was caused by commit
427e59f09fdba387547106de7bab980b7fff77be , something in the scsi layer.
More on linux-scsi (I'll Cc you)

Thanks

Mike.

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