* [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).