linux-kernel - Re: [PATCH 4/8] bio: actually inline inline bvecs into 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]

Date:	Wed, 1 Apr 2009 14:47:09 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	bharrosh@...asas.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/8] bio: actually inline inline bvecs into bio

On Wed, Apr 01 2009, Tejun Heo wrote:
> Impact: cleanup
> 
> BIO_INLINE_VECS bvecs are inlined into bio to avoid bvec allocation
> for small transfers.  This was achieved by declaring zero sized bvec
> array at the end of bio and allocating bio with extra bytes at the
> end.  As BIO_INLINE_VECS is constant, there is no reason to do this
> allocation trick.  This patch simply defines BIO_INLINE_VECS sized
> bvec array at the end.  This will help fixing bio_kmalloc().

I don't like this, it's much nicer to do it with a zero sized array. If
you don't need a bio_vec, then you don't consume the extra space. I
guess for that to really work, we'd need one more slab and mempool
though. At least for non-stack bio's. I also fear that direct uses of
->bi_inline_vecs[] will then crop up, making it harder to go back.

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