linux-kernel - Re: [patch v3] splice: fix race with page invalidation

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]

Date:	Wed, 30 Jul 2008 21:45:16 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	nickpiggin@...oo.com.au, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [patch v3] splice: fix race with page invalidation

On Wed, Jul 30 2008, Miklos Szeredi wrote:
> > On Wed, 30 Jul 2008, Jens Axboe wrote:
> > > You snipped the part where Linus objected to dismissing the async
> > > nature, I fully agree with that part.
> 
> And also note in what Nick said in the referenced mail: it would be
> nice if someone actually _cared_ about the async nature.  The fact
> that it has been broken from the start, and nobody noticed is a strong
> hint that currently there isn't anybody who does.

That's largely due to the (still) lack of direct splice users. It's a
clear part of the design and benefit of using splice. I very much care
about this, and as soon as there are available cycles for this, I'll get
it into better shape in this respect. Taking a step backwards is not the
right way forward, imho.

> Maybe fuse will be the first one to actually care, and then I'll
> bother with putting a lot of effort into it.  But until someone cares,
> nobody will bother, and that's how it should be.  That's very much in
> line with the evoultionary nature of kernel developments: unused
> features will just get broken and eventually removed.

People always say then, and the end result is it never gets done. Not to
point the finger at Nick, but removing the steal part of the splice
design was something I objected to a lot. Yet it was acked on the
premise that it would eventually get resubmitted in a fixed manner, but
were are not further along that path.

-- 
Jens Axboe

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