linux-kernel - Re: [PATCHSET pata-2.6] ide: rq->buffer, data, special and misc cleanups

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: <20090413163957P.fujita.tomonori@lab.ntt.co.jp>
Date:	Mon, 13 Apr 2009 16:41:59 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	bharrosh@...asas.com
Cc:	tj@...nel.org, petkovbb@...il.com, bzolnier@...il.com,
	linux-kernel@...r.kernel.org, axboe@...nel.dk,
	linux-ide@...r.kernel.org
Subject: Re: [PATCHSET pata-2.6] ide: rq->buffer, data, special and misc
	cleanups

On Tue, 31 Mar 2009 16:04:39 +0300
Boaz Harrosh <bharrosh@...asas.com> wrote:

> > I
> > just don't think bvec should be used outside of block/fs interface.
> > As I wrote before, non-FS users have no reason to worry about bio.
> > All it should think about is the requst it needs to issue and the
> > memory area it's gonna use as in/out buffers.  bio just doesn't have a
> > place there.
> > 
> 
> I don't understand what happens to all the people that start to work on the block
> layer, they start getting defensive about bio being private to the request
> level. But the Genie is out of the bag already (I know cats and bottles).
> bio is already heavily used above the block layer from directly inside filesystems
> to all kind of raid engines, DM MD managers, multi paths, integrity information ...
> 
> Because bio is exactly that Ideal page carrier you are talking about.

Wrong. multi path doesn't use bio. md accesses to the bio internal
(it's not nice) and has the own way to carry pages. dm has the own
mechanism on the top of bio. And bio doesn't work nicely for file
systems such as btrfs, which handle multiple devices.

Please stop your wrong argument 'bio is the ideal page carrier'.


> The usage pattern needed by everybody everywhere is:
> Allocate an abstract container starting empty. add some pages to it,
> grow / chain endlessly as needed, (or as constrained from other factors).
> Submit it down the stack. Next stage can re-use it, split it, merge it, mux
> it demux it, bounce it, hang event notifiers, the works.
--
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/