linux-kernel - Re: [PATCH]: block: try-2 (modified): Initialize bi_rw in mpage so bio

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E1B37B1.9030608@fusionio.com>
Date:	Mon, 11 Jul 2011 19:49:37 +0200
From:	Jens Axboe <jaxboe@...ionio.com>
To:	Muthu Kumar <muthu.lkml@...il.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH]: block: try-2 (modified): Initialize bi_rw in mpage so
  bio_add can make use of it.

On 2011-07-11 19:31, Muthu Kumar wrote:
> Jens et al,
> 
> do_mpage_readpage()/__mpage_writepage(): When they allocate a new bio,
> bi_rw is not initialized. So later when they call __bio_add_page(),
> struct bvec_merge_data bvm's .bi_rw will not be initialized with right
> direction.
> It will be useful for some merge functions if they know the direction
> of transfer.
> 
> Let me know if this looks good. There are few more places like this
> (e.g blkdev_issue_zeroout()). Would it make sense to send patch for
> these cases also?

For this particular case, doing it when the bio is allocated makes more
sense. That will avoid a similar error in there in the future.

Something ala the below.

diff --git a/fs/mpage.c b/fs/mpage.c
index fdfae9f..a2b8604 100644
--- a/fs/mpage.c
+++ b/fs/mpage.c
@@ -80,7 +80,7 @@ static struct bio *mpage_bio_submit(int rw, struct bio *bio)
 
 static struct bio *
 mpage_alloc(struct block_device *bdev,
-		sector_t first_sector, int nr_vecs,
+		sector_t first_sector, int nr_vecs, int rw,
 		gfp_t gfp_flags)
 {
 	struct bio *bio;
@@ -93,8 +93,9 @@ mpage_alloc(struct block_device *bdev,
 	}
 
 	if (bio) {
-		bio->bi_bdev = bdev;
 		bio->bi_sector = first_sector;
+		bio->bi_bdev = bdev;
+		bio->bi_rw = rw;
 	}
 	return bio;
 }
@@ -288,7 +289,7 @@ alloc_new:
 	if (bio == NULL) {
 		bio = mpage_alloc(bdev, blocks[0] << (blkbits - 9),
 			  	min_t(int, nr_pages, bio_get_nr_vecs(bdev)),
-				GFP_KERNEL);
+				READ, GFP_KERNEL);
 		if (bio == NULL)
 			goto confused;
 	}
@@ -580,7 +581,8 @@ page_is_mapped:
 alloc_new:
 	if (bio == NULL) {
 		bio = mpage_alloc(bdev, blocks[0] << (blkbits - 9),
-				bio_get_nr_vecs(bdev), GFP_NOFS|__GFP_HIGH);
+				bio_get_nr_vecs(bdev), WRITE,
+				GFP_NOFS|__GFP_HIGH);
 		if (bio == NULL)
 			goto confused;
 	}

-- 
Jens Axboe

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