linux-kernel - Re: [PATCH] block: don't make BLK_DEF_MAX

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: <20160329211833.GA18532@infradead.org>
Date:	Tue, 29 Mar 2016 14:18:33 -0700
From:	Christoph Hellwig <hch@...radead.org>
To:	Shaohua Li <shli@...com>
Cc:	linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
	axboe@...com, Kernel-team@...com, "4.2+" <stable@...r.kernel.org>,
	Ming Lei <ming.lei@...onical.com>
Subject: Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big

On Tue, Mar 29, 2016 at 09:42:33AM -0700, Shaohua Li wrote:
> bio_alloc_bioset() allocates bvecs from bvec_slabs which can only
> allocate maximum 256 bvec (eg, 1M for 4k pages). We can't bump
> BLK_DEF_MAX_SECTORS to exceed this value otherwise bio_alloc_bioset will
> fail.

This might be true, but it's not a good enough reason.  Request based
driver couldn't care less about the limits of bio_alloc_bioset.

It seems the bug is that somone (would be great to know whoe exactly)
passes a too large value to bio_alloc_bioset. And given that we still
have bio_add_page around for actually adding pages to a bio it seems
like the proper fix would be to simply clamp down the actual allocation
and segment limit inside bio_alloc_bioset.  Which would also help to
eventually remove code doing just that in tons of callers.