linux-kernel - Re: [rfc patch 3/4] splice: remove confirm from pipe_buf

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: <20080624114654.GA27123@2ka.mipt.ru>
Date:	Tue, 24 Jun 2008 15:46:54 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	jens.axboe@...cle.com, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	torvalds@...ux-foundation.org
Subject: Re: [rfc patch 3/4] splice: remove confirm from pipe_buf_operations

On Tue, Jun 24, 2008 at 01:36:35PM +0200, Miklos Szeredi (miklos@...redi.hu) wrote:
> > basically like PageWriteback(), but for read-in.
> 
> OK it could be done, possibly at great pain.  But why is it important?

Maybe not that great if mark all readahead pages as, well, readahead,
and do the same for readpage (essnetially it is the same).

> What's the use case where it matters that splice-in should not block
> on the read?

To be able to transfer what was already read?

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