Hi Dennis, Thank you for the patch! Yet something to improve: [auto build test ERROR on block/for-next] [also build test ERROR on v4.19-rc1 next-20180831] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Dennis-Zhou/blkcg-ref-count-refactor-cleanup-blkcg-avg_lat/20180831-161742 base: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git for-next config: x86_64-randconfig-x017-201834 (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): In file included from block/bounce.c:13:0: include/linux/bio.h:566:17: warning: 'struct blkcg_gq' declared inside parameter list will not be visible outside of this definition or declaration struct blkcg_gq *blkg) { return 0; } ^~~~~~~~ block/bounce.c: In function 'bounce_clone_bio': >> block/bounce.c:262:23: error: 'struct bio' has no member named 'bi_issue'; did you mean 'bi_disk'? bio_issue_init(&bio->bi_issue, bio_sectors(bio)); ^~~~~~~~ bi_disk vim +262 block/bounce.c 197 198 static struct bio *bounce_clone_bio(struct bio *bio_src, gfp_t gfp_mask, 199 struct bio_set *bs) 200 { 201 struct bvec_iter iter; 202 struct bio_vec bv; 203 struct bio *bio; 204 205 /* 206 * Pre immutable biovecs, __bio_clone() used to just do a memcpy from 207 * bio_src->bi_io_vec to bio->bi_io_vec. 208 * 209 * We can't do that anymore, because: 210 * 211 * - The point of cloning the biovec is to produce a bio with a biovec 212 * the caller can modify: bi_idx and bi_bvec_done should be 0. 213 * 214 * - The original bio could've had more than BIO_MAX_PAGES biovecs; if 215 * we tried to clone the whole thing bio_alloc_bioset() would fail. 216 * But the clone should succeed as long as the number of biovecs we 217 * actually need to allocate is fewer than BIO_MAX_PAGES. 218 * 219 * - Lastly, bi_vcnt should not be looked at or relied upon by code 220 * that does not own the bio - reason being drivers don't use it for 221 * iterating over the biovec anymore, so expecting it to be kept up 222 * to date (i.e. for clones that share the parent biovec) is just 223 * asking for trouble and would force extra work on 224 * __bio_clone_fast() anyways. 225 */ 226 227 bio = bio_alloc_bioset(gfp_mask, bio_segments(bio_src), bs); 228 if (!bio) 229 return NULL; 230 bio->bi_disk = bio_src->bi_disk; 231 bio->bi_opf = bio_src->bi_opf; 232 bio->bi_write_hint = bio_src->bi_write_hint; 233 bio->bi_iter.bi_sector = bio_src->bi_iter.bi_sector; 234 bio->bi_iter.bi_size = bio_src->bi_iter.bi_size; 235 236 switch (bio_op(bio)) { 237 case REQ_OP_DISCARD: 238 case REQ_OP_SECURE_ERASE: 239 case REQ_OP_WRITE_ZEROES: 240 break; 241 case REQ_OP_WRITE_SAME: 242 bio->bi_io_vec[bio->bi_vcnt++] = bio_src->bi_io_vec[0]; 243 break; 244 default: 245 bio_for_each_segment(bv, bio_src, iter) 246 bio->bi_io_vec[bio->bi_vcnt++] = bv; 247 break; 248 } 249 250 if (bio_integrity(bio_src)) { 251 int ret; 252 253 ret = bio_integrity_clone(bio, bio_src, gfp_mask); 254 if (ret < 0) { 255 bio_put(bio); 256 return NULL; 257 } 258 } 259 260 bio_clone_blkcg_association(bio, bio_src); 261 > 262 bio_issue_init(&bio->bi_issue, bio_sectors(bio)); 263 264 return bio; 265 } 266 --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
Attachment:
.config.gz
Description: application/gzip
