Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751409Ab3GPFbp (ORCPT ); Tue, 16 Jul 2013 01:31:45 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:47009 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751182Ab3GPFbo (ORCPT ); Tue, 16 Jul 2013 01:31:44 -0400 Date: Tue, 16 Jul 2013 06:31:40 +0100 From: Al Viro To: Linus Torvalds Cc: Dave Jones , Linux Kernel , Peter Zijlstra , Oleg Nesterov , Ben Myers , xfs@oss.sgi.com Subject: Re: splice vs execve lockdep trace. Message-ID: <20130716053140.GK4165@ZenIV.linux.org.uk> References: <20130716015305.GB30569@redhat.com> <20130716023847.GA31481@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1114 Lines: 20 On Mon, Jul 15, 2013 at 08:25:14PM -0700, Linus Torvalds wrote: > The "pipe -> cred_guard_mutex" lock chain is pretty direct, and can be > clearly attributed to splicing into /proc. Now, whether that is a > *good* idea or not is clearly debatable, and I do think that maybe we > should just not splice to/from proc files, but that doesn't seem to be > new, and I don't think it's necessarily *broken* per se, it's just > that splicing into /proc seems somewhat unnecessary, and various proc > files do end up taking locks that can be "interesting". FWIW, we might attack that one - after all, we could have ->splice_write() for that guy that would grab cred_guard_mutex, then call splice_from_pipe() with actor that would map/do security_setprocattr/unmap... Said that, considering what it does on write, it really does *not* want to deal with partial writes, so... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/