linux-kernel - Re: [PATCH 0/2] splice: i_mutex vs splice write deadlock

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: <20110719031003.GA18166@infradead.org>
Date:	Mon, 18 Jul 2011 23:10:03 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Dave Chinner <david@...morbit.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	xfs@....sgi.com
Subject: Re: [PATCH 0/2] splice: i_mutex vs splice write deadlock

I don't really like this very much.  Not taking the i_mutex at all
makes the splice_write method in XFS use different locking than
everyone else, and different from the normal XFS write path.

For example ocfs2 which has the same locking issues just has an
own implementation of the splice_write method, which isn't
too nice but at least marginally better.  I think the right
fix for both xfs and ocfs2 would be to have a generic_file_splice_write
variant that takes an "actor" function pointer, which defaults to
a smaller wrapper around file_remove_suid, file_update_time and
splice_from_pipe_feed, and then XFS and ocfs2 can provide their
own actors that add the additional locking.

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