* [block:for-next 7/35] fs/bio.c:363 bio_alloc_bioset() error: we previously assumed 'bs' could be nul @ 2012-09-09 12:15 Fengguang Wu 2012-09-09 12:22 ` [block:for-next 7/35] fs/bio.c:363 bio_alloc_bioset() error: we previously assumed 'bs' could be Jens Axboe 2012-09-17 22:49 ` Kent Overstreet 0 siblings, 2 replies; 3+ messages in thread From: Fengguang Wu @ 2012-09-09 12:15 UTC (permalink / raw) To: kernel-janitors Hi Kent, FYI, there are new smatch warnings show up in tree: git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git for-next head: 5611a9dbd54b993fe24f322a0c310a6605824c0f commit: 3f86a82aeb03e6100f7ab39f4702e033a5e38166 [7/35] block: Consolidate bio_alloc_bioset(), bio_kmalloc() All smatch warnings: + fs/bio.c:363 bio_alloc_bioset() error: we previously assumed 'bs' could be null (see line 327) arch/x86/include/asm/jump_label.h:25 arch_static_branch() info: ignoring unreachable code. --- 0-DAY kernel build testing backend Open Source Technology Centre Fengguang Wu <wfg@linux.intel.com> Intel Corporation ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [block:for-next 7/35] fs/bio.c:363 bio_alloc_bioset() error: we previously assumed 'bs' could be 2012-09-09 12:15 [block:for-next 7/35] fs/bio.c:363 bio_alloc_bioset() error: we previously assumed 'bs' could be nul Fengguang Wu @ 2012-09-09 12:22 ` Jens Axboe 2012-09-17 22:49 ` Kent Overstreet 1 sibling, 0 replies; 3+ messages in thread From: Jens Axboe @ 2012-09-09 12:22 UTC (permalink / raw) To: kernel-janitors On 2012-09-09 14:15, Fengguang Wu wrote: > Hi Kent, > > FYI, there are new smatch warnings show up in > > tree: git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git for-next > head: 5611a9dbd54b993fe24f322a0c310a6605824c0f > commit: 3f86a82aeb03e6100f7ab39f4702e033a5e38166 [7/35] block: Consolidate bio_alloc_bioset(), bio_kmalloc() The logic in there does look both confusing and broken. For !bs, we should not enter the bvec_alloc_bs() part. We already have the vec, plus bvec_alloc_bs() would crap out for !bs. That would exclude us from hitting err_free as well. Style issue on nr_iovecs check, too. -- Jens Axboe ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [block:for-next 7/35] fs/bio.c:363 bio_alloc_bioset() error: we previously assumed 'bs' could be 2012-09-09 12:15 [block:for-next 7/35] fs/bio.c:363 bio_alloc_bioset() error: we previously assumed 'bs' could be nul Fengguang Wu 2012-09-09 12:22 ` [block:for-next 7/35] fs/bio.c:363 bio_alloc_bioset() error: we previously assumed 'bs' could be Jens Axboe @ 2012-09-17 22:49 ` Kent Overstreet 1 sibling, 0 replies; 3+ messages in thread From: Kent Overstreet @ 2012-09-17 22:49 UTC (permalink / raw) To: kernel-janitors On Sun, Sep 09, 2012 at 02:22:26PM +0200, Jens Axboe wrote: > On 2012-09-09 14:15, Fengguang Wu wrote: > > Hi Kent, > > > > FYI, there are new smatch warnings show up in > > > > tree: git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git for-next > > head: 5611a9dbd54b993fe24f322a0c310a6605824c0f > > commit: 3f86a82aeb03e6100f7ab39f4702e033a5e38166 [7/35] block: Consolidate bio_alloc_bioset(), bio_kmalloc() > > The logic in there does look both confusing and broken. > > For !bs, we should not enter the bvec_alloc_bs() part. We already have > the vec, plus bvec_alloc_bs() would crap out for !bs. That would exclude > us from hitting err_free as well. Yeah, it is confusing, I wasn't entirely happy with that code but I wasn't able to come up with anything I really liked. The reason I wrote it the way I did is that before, bio_kmalloc() would always set bio->bi_io_vec = bio->bi_inline_vecs, even when nr_iovecs was 0, while bio_alloc_bioset() would set it to NULL. And this is what bio_has_data() checks, which is actually used in a decent number of places. So I wanted to unify the behaviour as much as possible, and not have duplicated code that could get out of sync again. Jens, what do you want to do? If you'd prefer I could always split out the two cases (bs and !bs) entirely and just note the bi_io_vec thing with a comment, though I do lean toward smaller code. Also wondering whether it'd be feasible/worthwhile to just drop bio_kmalloc() entirely and always use a bio_set. > Style issue on nr_iovecs check, too. How so? Not aware of any formal style rule it breaks... ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-09-17 22:49 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-09 12:15 [block:for-next 7/35] fs/bio.c:363 bio_alloc_bioset() error: we previously assumed 'bs' could be nul Fengguang Wu 2012-09-09 12:22 ` [block:for-next 7/35] fs/bio.c:363 bio_alloc_bioset() error: we previously assumed 'bs' could be Jens Axboe 2012-09-17 22:49 ` Kent Overstreet
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).