linux-kernel - Re: pipe/cred lockdep warning

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

Date:	Sat, 5 Oct 2013 02:42:29 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Dave Jones <davej@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: pipe/cred lockdep warning

On Fri, Oct 04, 2013 at 06:25:00PM -0700, Linus Torvalds wrote:

> Any splice user has better have a fallback to a read/write loop anyway, so
> I think the default of trying to splice was likely a bad decision.

Ummm...  Point.

> That said, you're right that it's a big change. And maybe we don't really
> care enough, and we should just make sure sysfs and proc get the EINVAL
> return. So it's not like I have a really strong preference.
> 
> But I *definitely* don't want something that just sets every f_op to use
> the default splice write. That's just equivalent to our current default to
> possibly bad behavior..

Well, I meant something like this: at 3.13-rc1 we add two exported
functions calling default_file_splice_write() - fallback_file_splice_write()
and this_fucker_will_be_gone_in_3_14_rc1_splice_write().  And do a single
commit slapping the latter in those file_operations.  After that NULL means
-EINVAL.  At which point maintainers are welcome to review the damn thing and
either remove the initializer if for this instance it makes no sense, or
switch it to something that will stay.  Maybe fallback_file_splice_write(),
maybe something else - up to them.  I wouldn't be surprised if in some cases
generic_file_splice_write() would turn out to be the right answer.  In any
case, in 3.14-rc1 the function gets treatment according to its name and
those who hadn't bothered to switch are left with obvious build errors.
Should be a sufficient incentive to get off their arses and deal with that by
the time 3.14 comes...

It would work and it would avoid incompatible changes, but I agree that
anything using splice in userland ought to have a fallback...  Dunno.
It's definitely not something to be done before .13-rc1, so we have time
to discuss that anyway.
--
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/