linux-kernel - Re: [PATCH] sendfile removal

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: <20070604112214.GA7457@mail.ustc.edu.cn>
Date:	Mon, 4 Jun 2007 19:22:14 +0800
From:	Fengguang Wu <fengguang.wu@...il.com>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Eric Dumazet <dada1@...mosbay.com>,
	linux-kernel@...r.kernel.org, cotte@...ibm.com, hugh@...itas.com,
	neilb@...e.de, zanussi@...ibm.com, hch@...radead.org
Subject: Re: [PATCH] sendfile removal

On Mon, Jun 04, 2007 at 10:05:35AM +0200, Jens Axboe wrote:
> On Mon, Jun 04 2007, Fengguang Wu wrote:
> > Hi Jens,
> > 
> > This is another try, still not in a comfortable state though.
> > //Busy waiting is possible for interleaved reads.
> 
> A few random comments...
> 
> Adding an internal flag is fine, but please put it at the upper end of
> the spectrum. So, use (1 << 31) for that flag.

OK.

> And please work on the #splice branch of the block repo, not -mm. There
> are quite a few things pending for inclusion in there, and I'm sure your
> patch as-is wont apply.

I'm afraid this patch cannot be moved over to your branch trivially.

The core of the algorithm reuses f_ra.prev_index to record the state.
It is OK for the on-demand readahead in the -mm tree. But the current
readahead code in 2.6.22-rc3 is sensible to the change. And it also
does not reliably tell if readahead I/O has been submitted.

We can either try other ways of doing non-blocking I/O, or just wait
until the merge of on-demand readahead?

The current patch should work perfect with single splice reader. In
the case of multiple readers on the same fd, we might simply err on
the side of I/O waiting, since busy EAGAIN looping is not acceptable.

Fengguang Wu

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