linux-kernel - Re: [PATCH] brd: Ensure that bio_vecs have size <= PAGE

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] [day] [month] [year] [list]

Message-ID: <5501BF2F.6010303@plexistor.com>
Date:	Thu, 12 Mar 2015 18:30:39 +0200
From:	Boaz Harrosh <boaz@...xistor.com>
To:	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	Jens Axboe <axboe@...com>
CC:	linux-kernel@...r.kernel.org,
	"Roger C. Pao (Enmotus)" <rcpao.enmotus@...il.com>,
	linux-nvdimm@...ts.01.org, Nick Piggin <npiggin@...nel.dk>
Subject: Re: [PATCH] brd: Ensure that bio_vecs have size <= PAGE_SIZE

On 03/12/2015 12:42 AM, Ross Zwisler wrote:
<>
> 
> Anyway, I thought your response to the original bug report against PMEM was
> that you were alright with this one line change since it didn't hurt anything,
> and perhaps it helped someone.  Do you have the same stance for BRD, 

No what I did in pmem is remove the BUG that was borrowed from brd, because
in pmem we can support any imaginary bv_len since we are always contiguous
in memory. (And Kernel mapping of a contiguous physical pages is also
contiguous physical in virtual space)

> or do you
> think we need to track down if or how bio_vecs can make it to the driver with
> more than one page of data first?
> 

OK So I have (again) audited every instance of *max_segment_size* and call
me slow and stupid but all I can see is that:

All this "coalesce"ing behavior and any reference to max_segment_size that
you guys are talking about happen when translating the bio to an sg_list.

In fact think about it the block layer must not touch the bio+biovec because
it is a contract with upper layer. for each page submission there must be a
one-to-one end_io notification for instance an FS might have taken a page_lock
on the page.
So if what you are saying is true and "bios are coalesced" it means that you
need to copy the original bio-list to a new compacted one. This does not
happen the copy to a new list happens from the move from bio to an sg_list,
and the original bio is untouched.

That said this is all up to Jens he is the maintainer of the block layer, if
you are correct and bv_len may ever be > PAGE_SIZE then he will gladly take
this patch I'm sure.

> - Ross

Just that I would really like to understand, that's all

Thanks
Boaz

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